# Will AudioProcessor::isNonRealtime() ever need to lock?

**URL:** <https://forum.juce.com/t/will-audioprocessor-isnonrealtime-ever-need-to-lock/46062>\
**Category:** General JUCE discussion\
**Created:** [May 17, 2021, 7:30pm UTC](https://forum.juce.com/t/will-audioprocessor-isnonrealtime-ever-need-to-lock/46062 "2021-05-17T19:30:06Z")\
**Posts on this page:** 1\
**Page:** 1

<div class="post-metadata">

**Author:** ![zac](https://avatars.discourse-cdn.com/v4/letter/z/87869e/32.png) [@zac](https://forum.juce.com/u/zac)\
**Post date:** [May 17, 2021, 7:30pm UTC](https://forum.juce.com/t/will-audioprocessor-isnonrealtime-ever-need-to-lock/46062/1 "2021-05-17T19:30:07Z")

</div>

I noticed [this recent commit](https://github.com/juce-framework/JUCE/commit/c8dae58fd211ee364f641787e97bf7f279a914ef) which, while it doesn’t change anything for the moment, made me worry about whether changes like this might occur to the API in the future.

I use isNonRealtime() on the audio thread to check whether we should lock to wait for the message thread to catch up with the audio thread in offline bounce situations. I checked the sources and saw that isNonRealtime() just returns a bool member variable, and doesn’t pose me any risk. In the future though, would a change be likely or possible which would make isNonRealtime() lock? If so, it’s not a huge deal – I can obviously just use an atomic and check for changes to realtime status in prepareToPlay (assuming prepareToPlay would be called during transitions between realtime and non-realtime states). But it’d be pretty hard to debug if I built against JUCE in 3 years and got a crackly buffer at the first playback after an offline bounce.

In general, should I look into JUCE classes to check for these sorts of things and assume they won’t change, or will these sorts of changes be possible?