I couldn't agree with Victor more.
It is possible to design and implement an underlying thread
implementation that requires priority inheritance because of
preemption. Since Linux doesn't preempt kernel tasks except to handle
interrupts (which are defined to be bugful if they cause the task to
block), this isn't an issue. Priority inheritance, as Victor points
out, only becomes attractive because programmers want to do things
that case lock-holding threads to block.
Being able to write:
lock();
ENTER_CRITICAL_SECTION();
block();
LEAVE_CRITICAL_SECTION();
unlock();
is what priority inheritance gives you, at some considerable cost. The
cheap alternative is to require a certain coding discipline, as with
drivers in the kernel, and always do:
lock(&lock);
ENTER_CRITICAL_SECTION();
condition_semantics_block (&lock); unlocks lock before block)
/* condition is now true, lock is now held */
/* possibly check assumptions derived before block */
LEAVE_CRITICAL_SECTION();
unlock(&lock);
With this discipline, you don't need priority inheritance, since no
blocked thread ever holds a lock.
>And think about why it's important to use this mechanism for
>semaphores but not important when exactly the same type of "inversion"
>can happen on, for exa mple, memory allocation with sleeps -- just
>because you don't call it a semaphore do es not mean it does not have
>the same semantics.
Thanks for another great example of deadlock semantics.
--p
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/