On Wed, May 24, 2000 at 09:10:44AM +1200, Russ Swatek wrote:
> I guess I do not understand the reason to absolutely prohibit (i.e. not
> provide) priority inheritance capability.  It is incumbent on the

It's quite easy for someone else to provide such a facility. We don't
because we think it causes failure prone code.

> designer/developer to use it correctly just as they must do for all
> other capabilities.

I don't think there is a correct way to use priority inheritance. Of course,
any synchronization method can be used incorrectly, but that is quite
a different issue.

> Some threads absolutely may never block, and they must use some form of
> async notification (or polling across multiple activations) to acquire a
> critical resource.  (In RTLinux what is the best way to implement a
> prioritized queueing for a critical resource with async notification?)

One simple method is to pass a token in a RTfifo.

> Many threads can block briefly.  Priority inheritance works well for
> these threads.  When computing the maximum elapsed time for these
> threads the maximum time needed to acquire all required critical
> resources must also be added in to the calculation.  These additional
> max acquisition times are much less if the critical resource holders
> receive a priority boost until they surrender the resource.  Of course

Not necessarily. For example:
            Thread A acquires semaphore X and then does blocking I/O
            Thread B  blocks on X
there are many other examples. The all lead to the conclusion that if you
have sufficiently analyzed the code to use priority inheritance safely
you can dispense with  it entirely.

It's not as if there are no alternatives.

-- 
---------------------------------------------------------
Victor Yodaiken 
FSMLabs:  www.fsmlabs.com  www.rtlinux.com
FSMLabs is a servicemark and a service of 
VJY Associates L.L.C, New Mexico.

-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl <Your_email>" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/

Reply via email to