Hi Fabian,

yes, it will work the way you described, and yes, whenever accessing shared resources, you should take care that this 
access will take place in a way that guarantees data integrity. Sometimes it can be sufficient to use atomic operations 
(atomic_*()-functions), often you'll need mutexes, sometimes condvars are appropriate, sometimes it even makes sense to 
use message passing for synchronization.

Regarding your question how QNX 'knows' that thread B (low priority) must be boosted - there are two aspects to it:
- How can the OS know it's thread B that must be boosted and
- how can it tell B needs any boosting at all?

For the first aspect, when thread A tries to lock the mutex, the OS knows that thread B currently owns the mutex. It 
also knows that B has a lower effective priority than A and thus needs a boost.

As for the second aspect, we can distinguish two cases:
- Some thread with a priority > B wants the CPU before B releases the mutex
- No higher-priority (than B) thread wants the CPU

The OS cannot know (at the time when A becomes MUTEX-blocked) what will happen - so the best solution is to always boost
. If a third thread with a priority > B and <= A does become READY, priority inversion will be avoided by boosting. If 
no one else wants the CPU, it doesn't matter what priority B is running at, anyway.

Of course, in the latter case we boost 'too much' - we could spare the effort of adjusting B's priority. But the actual 
effort to do so is minimal, much less than determining whether B needs boosting whenever another thread gets READY while
 B still holds the mutex.

Regards,
- Thomas