|This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
Priority inversion occurs when a high priority thread is blocked from running because a lower priority thread owns a kernel object, such as a mutex or critical section, that the high priority thread needs. For example, a Windows CE application contains threads 1, 2, and 3. Thread 1 is high priority currently scheduled thread and it tries to acquire a critical section owned by Thread 2. Thread 2 could be in one of two states:
In case (1), Thread 1 would block and Thread 2 would be boosted to the priority of Thread 1 in hopes that it will release the critical section. IN case (2) Thread 2 would be boosted along with Thread 3 and any other thread that was connected in the chain.
In contrast, Windows CE 3.0 guarantees the handling of priority inversion only to a depth of one level for case (2). Therefore, Thread 1 will block until Thread 2 gives up the critical section. Thread 2 and 3 will be scheduled based on a normal scheduling algorithm In a real-time system priority inversion cases are to be avoided for the basic reason that you loose control on the scheduling of your threads. Controlling the exact timing of a thread in a real-time environment is very important.
Last updated on Tuesday, May 18, 2004