[EMAIL PROTECTED] wrote:
>
> I think this is exactly the kind of design that should not be made to
> rely on priority inheritance but instead should use reliable and safe
> programming methods. To avoid priority inversion does not require
> brilliant programming, it requires use of well known, time-tested
> methods such as flip buffers and message queues (or RTfifos).
> The semantics for a semaphore are quite clear
> semaphore_lock == while (atomic_test_and_lock() == ALREADY_LOCKED)
> suspend the current thread
>
> That is, semaphores involve the possibility of _unbounded_ delay.
> It's terribly dangerous to try to pretend otherwise and it's
> totally unnecessary.
> The rules are very simple:
> use a "handshake" method when suspending the thread
> is ok.
> use an asynchronous method when the thread must not
> block.
>
> safety requires simplicity and simplicity is hard.
>
I guess I do not understand the reason to absolutely prohibit (i.e. not
provide) priority inheritance capability. It is incumbent on the
designer/developer to use it correctly just as they must do for all
other capabilities.
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?)
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
in most cases it is again incumbent on the designer/developer to insure
that no critical resource holder ever blocks except for a critical
resource for which priority inheritance is enabled.
When the timeline of a thread is being computed the following factors
need to be considered:
1. The timeline of all threads/ISRs that may preempt the subject
thread.
2. The timeline of the subject thread in the perfect world (i.e. no
preemptions and all required critical resources immediately available).
3. The time for each critical resource required by the subject thread
to be released by a normally lower priority thread executing at the same
priority as the subject thread. This time must only be added once for
each resource, since once freed it will not be acquired again by a lower
priority thread until the subject thread is done with it. Again this is
assuming that the subject thread does not block except while waiting for
a critical resource for which priority inheritance is enabled.
Russ Swatek
Range System Engineering
Kwajalein, Marshall Islands
-- [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/
