# Class for detecting unsafe operations in realtime contexts **URL:** \ **Category:** Audio Plugins\ **Created:** [February 9, 2018, 10:22am UTC](https://forum.juce.com/t/class-for-detecting-unsafe-operations-in-realtime-contexts/26330 "2018-02-09T10:22:55Z")\ **Posts on this page:** 10\ **Page:** 1
**Author:** ![yfede](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yfede/32/506_2.png) [@yfede](https://forum.juce.com/u/yfede)\ **Post date:** [February 9, 2018, 10:22am UTC](https://forum.juce.com/t/class-for-detecting-unsafe-operations-in-realtime-contexts/26330/1 "2018-02-09T10:22:55Z")
Following-up the discussion started in [this other topic](https://forum.juce.com/t/calling-setvaluenotifyinghost-from-processblock/26073), I’ve had a go at trying to implement a feature proposed there by @jules . The intention is to mark the sections of code that are intended for realtime execution (e.g. audio callbacks in plug-ins), and to provide a way for checking whether the current thread is inside one of those. This way, it will be possible to scatter `jassert`s in parts of code that are NOT safe for realtime usage, detecting whether they unintentionally end up being called by the audio threads. The core of the feature is implemented by the following class. I’ve intentionally NOT named it after something audio-related for two reasons: a) It’s not mandatory that realtime-sensitive contexts are audio-related only b) for the check to be available everywhere in JUCE and downstream, this should be added to the `juce_core` module, hence explicitly mentioning audio there would seem awkward. ``` class RealtimeSection { public: RealtimeSection() { RealtimeSection::getRecursionLevel() = RealtimeSection::getRecursionLevel().get() + 1; } ~RealtimeSection() { RealtimeSection::getRecursionLevel() = RealtimeSection::getRecursionLevel().get() - 1; } static bool isCurrentThreadInside() { return (RealtimeSection::getRecursionLevel().get() > 0); } private: static ThreadLocalValue & getRecursionLevel() { static ThreadLocalValue recursionLevel; return recursionLevel; } }; ``` Usage is simple: a `RealtimeSection` object should be created on the stack at the beginning of the audio callback of each plug-in format wrapper. Then, checking that non-realtime-safe code is not unintentionally executed by the audio thread is simply done with: ``` jassert (RealtimeSection::isCurrentThreadInside() == false); ``` What do you think? ---
**Author:** ![matkatmusic](https://avatars.discourse-cdn.com/v4/letter/m/dfb087/32.png) [@matkatmusic](https://forum.juce.com/u/matkatmusic)\ **Post date:** [February 10, 2018, 10:39pm UTC](https://forum.juce.com/t/class-for-detecting-unsafe-operations-in-realtime-contexts/26330/2 "2018-02-10T22:39:09Z")
this is probably my newbness showing itself. Would the intention be more obvious that you’re trying to update the `recursionLevel` variable if you changed the signature for your static method to this: ```auto static ThreadLocalValue* getRecursionLevel() { static ThreadLocalValue recursionLevel; return &recursionLevel; } ``` and the usage then became: ```auto *RealtimeSection::getRecursionLevel() = RealtimeSection::getRecursionLevel()->get() + 1; ``` I’m a big fan of being able to see intention immediately in code with either the syntax used or the variable names. If I didn’t take a look at the API for ThreadLocalValue, your class would have been very confusing to understand the intent and mechanics. I understand that you’re taking advantage of this method a lot to do your work: ```auto Type& ThreadLocalValue< Type >::operator*() const Returns a reference to this thread's instance of the value. ``` however, the intention ends up being hidden when syntax like what you wrote gets used. For me, when I see `function() = function() + 1;` I can’t tell that the author is trying to modify the internal value `function()` is statically providing. and I’m pretty sure ##c++general would consider that a code smell lol thoughts? ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [February 11, 2018, 8:09am UTC](https://forum.juce.com/t/class-for-detecting-unsafe-operations-in-realtime-contexts/26330/3 "2018-02-11T08:09:27Z")
Nope. Always choose a reference rather than a raw pointer if you can. Raw pointers create ambiguity about ownership of the object, and whether it can be null or not. Modern C++ style generally advises the avoidance of raw pointers at all cost. ---
**Author:** ![matkatmusic](https://avatars.discourse-cdn.com/v4/letter/m/dfb087/32.png) [@matkatmusic](https://forum.juce.com/u/matkatmusic)\ **Post date:** [February 11, 2018, 8:11am UTC](https://forum.juce.com/t/class-for-detecting-unsafe-operations-in-realtime-contexts/26330/4 "2018-02-11T08:11:33Z")
ok but `function() = function() + 1` is kinda awful. can we agree on that? it’s not obvious what the intention is. something like ```auto var = function() + 1; updateFunction(var); ``` is much clearer, even if it introduces a temporary variable. At the very least, don’t use a function that begins with “get” to set a value lol ---
**Author:** ![jules](https://avatars.discourse-cdn.com/v4/letter/j/41988e/32.png) [@jules](https://forum.juce.com/u/jules)\ **Post date:** [February 11, 2018, 10:16am UTC](https://forum.juce.com/t/class-for-detecting-unsafe-operations-in-realtime-contexts/26330/5 "2018-02-11T10:16:06Z")
I think what’s confusing you is that the code above is written in a bit of a cumbersome way. What you’d actually write would be more like ``` RealtimeSection() { auto& level = RealtimeSection::getRecursionLevel(); level = level.get() + 1; } ``` ---
**Author:** ![yfede](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yfede/32/506_2.png) [@yfede](https://forum.juce.com/u/yfede)\ **Post date:** [February 11, 2018, 1:34pm UTC](https://forum.juce.com/t/class-for-detecting-unsafe-operations-in-realtime-contexts/26330/6 "2018-02-11T13:34:13Z")
Yes, @matkatmusic, I admit that my code above looks better after some polishing: - renamed `getRecursionLevel()` to `getRecursionCounter()`, to convey the meaning that it is not returning a primitive value like an `int` (which would look awkward on the left side of assignments), but rather an object that works as a counter for the recursion level. To make it extra clear, the word “Reference” could be appended, too, but it seemed overkill in this case since it’s just an internal method after all. - used a local variable `recursionCounter` in both constructor and destructor to avoid clutter and confusion in the increment and decrement operations happening there. The code in my first post was like that because my very first implementation used a `static ThreadLocalValue` **member**. When switching to the better practice of holding it in a `static` **method** , I simply replaced occurrences of the member with invocations to the method. My bad for not spotting this earlier. Also thanks @jules for reminding the usefulness of `auto` in this context. - added a `jassert` to catch the (seemingly impossible) case of decrementing the counter into the negatives. Certanly that would indicate a problem! Apart from those, I side with jules regarding the pointer thing: I think that the above changes make the code clear enough not to require an explicit returning of a pointer which, as pointed out, creates ambiguity w.r.t. ownership and whether nullptr is a valid value. A reference in this case has none of those ambiguities and is therefore a better choice IMHO. The code now looks like this (still it lacks a proper documentation block. Adding the simplest usage example there would be the final touch but I don’t have time at the moment): ``` class RealtimeSection { public: RealtimeSection() { auto& recursionCounter = RealtimeSection::getRecursionCounter(); recursionCounter = recursionCounter.get() + 1; } ~RealtimeSection() { auto& recursionCounter = RealtimeSection::getRecursionCounter(); recursionCounter = recursionCounter.get() - 1; jassert (recursionCounter.get() >= 0); } static bool isCurrentThreadInside() { return (RealtimeSection::getRecursionCounter().get() > 0); } private: static ThreadLocalValue & getRecursionCounter() { static ThreadLocalValue recursionLevel; return recursionLevel; } }; ``` ---
**Author:** ![yfede](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/yfede/32/506_2.png) [@yfede](https://forum.juce.com/u/yfede)\ **Post date:** [February 13, 2018, 10:22am UTC](https://forum.juce.com/t/class-for-detecting-unsafe-operations-in-realtime-contexts/26330/7 "2018-02-13T10:22:27Z")
One further consideration: because `ThreadLocalValue` itself performs an allocation on the heap the first time it is accessed from a new thread, I propose also adding the following method to the above class. ``` /** Preallocates the internal ThreadLocalValue object for the current thread, so that even the first usage of RealtimeSection on this thread will not cause an allocation at a realtime-critical moment. For example, for audio plug-ins this could be called by the wrapper in the same context where prepareToPlay() is called. That will work on the assumption that the thread performing said initialization will be the same which will perform the processing. If such assumption does not hold, this will cost a single allocation for each thread doing the processing, which may be a tolerable behavior for a Debug build but should probably be avoided in Release */ static void willBeUsedInCurrentThread() { RealtimeSection::getRecursionCounter().get(); } ``` ---
**Author:** ![chkn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/chkn/32/3862_2.png) [@chkn](https://forum.juce.com/u/chkn)\ **Post date:** [February 13, 2018, 10:50am UTC](https://forum.juce.com/t/class-for-detecting-unsafe-operations-in-realtime-contexts/26330/8 "2018-02-13T10:50:50Z")
The problem i see with this, this may can lead people to have a false positive information, that their code is realtime safe, because it doesn’t assert, but I don’t think it’s wrong either. When i ever had realtime problems, this was never caused by performance intrusion or memory allocations, it were always different things. I would appreciate if juce has finished patterns that solve specific performance/realtime problems. - clever scoped time measures objects, which write logs with minimum/maximum/average timing, which can used all around the code to observe potential problems - a multipurpose realtime allocator, which can be used for non heavy weight objects - implement realtime-save versions of sendChangeMessage()/triggerAsyncUpdate and other functions like that - a read only valueTree ghost-copy which can be used for example in the audio-thread things like that ---
**Author:** ![matkatmusic](https://avatars.discourse-cdn.com/v4/letter/m/dfb087/32.png) [@matkatmusic](https://forum.juce.com/u/matkatmusic)\ **Post date:** [February 13, 2018, 10:08pm UTC](https://forum.juce.com/t/class-for-detecting-unsafe-operations-in-realtime-contexts/26330/9 "2018-02-13T22:08:53Z")
have you seen this: [https://juce.com/doc/classScopedTimeMeasurement](https://juce.com/doc/classScopedTimeMeasurement) ---
**Author:** ![chkn](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/chkn/32/3862_2.png) [@chkn](https://forum.juce.com/u/chkn)\ **Post date:** [February 13, 2018, 11:00pm UTC](https://forum.juce.com/t/class-for-detecting-unsafe-operations-in-realtime-contexts/26330/10 "2018-02-13T23:00:25Z")
Yes