# ScopedLock & CriticalSection question **URL:** \ **Category:** General JUCE discussion\ **Created:** [May 25, 2016, 10:27am UTC](https://forum.juce.com/t/scopedlock-criticalsection-question/17840 "2016-05-25T10:27:29Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![ckhf](https://avatars.discourse-cdn.com/v4/letter/c/e56c9b/32.png) [@ckhf](https://forum.juce.com/u/ckhf)\ **Post date:** [May 25, 2016, 10:27am UTC](https://forum.juce.com/t/scopedlock-criticalsection-question/17840/1 "2016-05-25T10:27:29Z")
I just noticed that I have some code similar to the following and was wondering why it worked: ```auto class Class { void foo() { ScopedLock lock(criticalSection); // ... } void bar() { ScopedLock lock(criticalSection); // ... foo(); // ... } CriticalSection criticalSection; }; ``` In `bar()` a ScopedLock is used and later `foo()` is called. What I’d expect is that the lock in `foo()` can’t enter the `criticalSection` mutex as it is already used in `bar()` but it simply works. A further thought would be that the mutex is thread-dependent and the lock in `foo()` therefore doesn’t block. But in that case the mutex might be released twice (when exiting `foo()` and again when exiting `bar()` which also doesn’t sound very good. I will rewrite the code so `foo()` can be called without creating a lock in case the mutex is already in use but I was wondering whether the above code is not as bad as it looks to me right now. This is on Windows if this might make any difference. ---
**Author:** ![martinrobinson-2](https://sea2.discourse-cdn.com/flex026/user_avatar/forum.juce.com/martinrobinson-2/32/630_2.png) [@martinrobinson-2](https://forum.juce.com/u/martinrobinson-2)\ **Post date:** [May 25, 2016, 11:41am UTC](https://forum.juce.com/t/scopedlock-criticalsection-question/17840/2 "2016-05-25T11:41:56Z")
It depends whether you call `foo()` and `bar()` from different threads. If the critical section isn’t locked and you call `bar()` then when the `foo()` is called in turn and the lock succeeds (as it is already locked by the that thread). On Mac, Linux and other POSIX the critical sections use PTHREAD\_MUTEX\_RECURSIVE so a lock count is maintained to allow this to work. (The Windows Enter/LeaveCriticalSection functions that JUCE uses use the same principle.) If the critical section is already locked by another thread then calling either function on another thread will block. ---
**Author:** ![ckhf](https://avatars.discourse-cdn.com/v4/letter/c/e56c9b/32.png) [@ckhf](https://forum.juce.com/u/ckhf)\ **Post date:** [May 25, 2016, 12:19pm UTC](https://forum.juce.com/t/scopedlock-criticalsection-question/17840/3 "2016-05-25T12:19:43Z")
Thanks for the reply. So if I understand correctly, the above code as such is OK and can be expected to work on Windows as well as Unix/Linux. Is this good style? ---
**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:** [May 25, 2016, 1:03pm UTC](https://forum.juce.com/t/scopedlock-criticalsection-question/17840/4 "2016-05-25T13:03:55Z")
Is this good style? Why not? ---
**Author:** ![ckhf](https://avatars.discourse-cdn.com/v4/letter/c/e56c9b/32.png) [@ckhf](https://forum.juce.com/u/ckhf)\ **Post date:** [May 25, 2016, 1:49pm UTC](https://forum.juce.com/t/scopedlock-criticalsection-question/17840/5 "2016-05-25T13:49:32Z")
For the unknowing eye (e.g. me three hours ago 🙂 ) it might appear prone to break as one lock might block the other. The reason that it works doesn’t necessarily mean that it is the best implementation. ---
**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:** [May 25, 2016, 4:09pm UTC](https://forum.juce.com/t/scopedlock-criticalsection-question/17840/6 "2016-05-25T16:09:04Z")
But it happens on the same thread, so (theoretically) there can’t be a race condition, because you now what you call inside the scoped-lock. Other kind of locks may behave differently, for example Juce’s SpinLock does not allow re-entrance. ---
**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:** [June 6, 2016, 11:04am UTC](https://forum.juce.com/t/scopedlock-criticalsection-question/17840/7 "2016-06-06T11:04:28Z")
(is it just me or “chkn” and “ckhf” are way too similar as usernames? without a telling profile picture, I was surprised to see the expert “chkn” asking such a basic question about locks, only to realize when he actually chimed in, that the OP was another user instead 😂) ---
**Author:** ![jpoag](https://avatars.discourse-cdn.com/v4/letter/j/bbe5ce/32.png) [@jpoag](https://forum.juce.com/u/jpoag)\ **Post date:** [June 7, 2016, 3:19pm UTC](https://forum.juce.com/t/scopedlock-criticalsection-question/17840/8 "2016-06-07T15:19:46Z")
So the short answer is: No. This is not good design. The longer answer depends on the implementation of the locking mechanism itself and (as it has been pointed out) whether or not the lock is re-entrant. A better design is as follows: use a public interface that acquires the lock(s) and private methods that perform the actions. The private implementations never call the public methods. [code] class CriticalResource { public: ``` // Public Interface void foo(){ ScopedLock lock(criticalSection); _foo(); } void bar(){ ScopedLock lock(criticalSection); _bar(); } ``` private: CriticalSection criticalSection; private: // Internal Implementation void \_foo() { \_bar(); } void \_bar() { … } }[/code] This also makes it easier if you need to solve lock-order related race conditions (Deadlock). In those situations, you create a well defined ‘order-of-the-locks’ that you always acquire in the same order. Even if you aren’t acquiring all of the locks. [code] // Well defined locking order: ALWAYS acquire locks in this order! // FOO\_LOCK // BAR\_LOCK class CriticalResource { public: ``` // Public Interface void foo(){ ScopedLock foo_lock(fooSection); ScopedLock bar_lock(barSection); // _foo() uses bar resource _foo(); } void bar(){ ScopedLock bar_lock(barSection); _bar(); } ``` private: CriticalSection fooSection; CriticalSection barSection; private: // Internal Implementation void \_foo() { /_Foo Resource_/ … ; \_bar(); } void \_bar() { /_Bar Resource_/ … } }[/code] When a lock fails to acquire, it goes to sleep and waits for a signal. As long as the locks are always acquired in the same order (regardless of which locks are and are not used), this will prevent a deadlock situation.