Re: [boost] Re: Threads: rw_mutex design + sample implementation

From: Carl Daniel (cpdaniel_at_[hidden])
Date: 2002-03-11 10:53:32

From: "danl_miller" <danl_miller_at_[hidden]>
>   Intrinsic in these 3 choices is that the preference
> applies only to threads with the same thread-priority
> metric.  If a lower-priority thread acquires an exclusive
> lock (i.e., the superior write lock in rwmutex), then
> higher-priority threads request a shared lock (i.e., the
> inferior read lock in rwmutex), then in many environments
> (e.g., RTOSes, DBMSes) the over-all system can enter a state
> where the lower-priority thread is never scheduled to run
> and the higher-priority threads all block due to their
> inferior lock requests, waiting for this never-scheduled
> lower-priority thread to release its superior lock.  In some
> system-states, the lower-priority thread will never be
> scheduled to execute and thus will never be able to get
> around to executing the code which releases its superior
> lock.  Thus a deadlock situation occurs.  This case is
> called priority inversion.

This is not quite the classical example of priority inversion, IIRC.  What's needed is a 3rd (cpu-bound) thread with a
priority intermediate to the other two.  The low priority thread which holds the lock cannot be scheduled because the
intermediate priority thread is always ready, therefore the lower thread never runs, the lock is never released, and a
priority inversion occurs between the intermediate thread and the (blocked) high-priority thread.  The only solution
I've encountered (various RTOS's, Windows) is to raise the priority of the lock-holding thread to equal that of the
lock-waiting thread, thus allowing it to run.  Once the lock is released, the priorities are returned to normal.  Of
course, the better solution is to design the system so that high and low priority work never compete for resources.

-cd