Editing Real-time operating system (section)

===Mutexes===
When the shared resource must be reserved without blocking all other tasks (such as waiting for Flash memory to be written), it is better to use mechanisms also available on general-purpose operating systems, such as a [[mutex]] and OS-supervised interprocess messaging. Such mechanisms involve system calls, and usually invoke the OS's dispatcher code on exit, so they typically take hundreds of CPU instructions to execute, while masking interrupts may take as few as one instruction on some processors.

A (non-recursive) mutex is either '''locked''' or unlocked. When a task has locked the mutex, all other tasks must wait for the mutex to be unlocked by its '' owner'' - the original thread. A task may set a timeout on its wait for a mutex. There are several well-known problems with mutex based designs such as [[priority inversion]] and [[deadlock (computer science)|deadlock]]s.

In [[priority inversion]] a high priority task waits because a low priority task has a mutex, but the lower priority task is not given CPU time to finish its work. A typical solution is to have the task that owns a mutex 'inherit' the priority of the highest waiting task. But this simple approach gets more complex when there are multiple levels of waiting: task ''A'' waits for a mutex locked by task ''B'', which waits for a mutex locked by task ''C''. Handling multiple levels of inheritance causes other code to run in high priority context and thus can cause starvation of medium-priority threads.

In a [[deadlock (computer science)|deadlock]], two or more tasks lock mutex without timeouts and then wait forever for the other task's mutex, creating a cyclic dependency. The simplest deadlock scenario occurs when two tasks alternately lock two mutex, but in the opposite order. Deadlock is prevented by careful design.