On Thu, Jul 11, 2002 at 04:31:18PM +0200, Martijn Sipkema wrote:
> When implementing a FIFO that is read by a low priority thread and written
> by a higher priority thread (SCHED_FIFO) that is not allow to block when
> writing the FIFO for a short, bounded time. Then if access to the FIFO is
> controlled using a mutex without some means to prevent priority inversion,
> the high priority thread can block indefinately on the mutex.
There are better solutions. For example, in RTLinux, fifos shared
between Linux (non-rt) processes and RT threads are asymmetric: the
RT thread never blocks, the non-RT thread blocks. In many cases
it is best to optimize the data operations and perform them under
a spin_lock with interrupts disabled. In RTLinux pthread_spin_lock
disables irqs and, in SMP also sets the lock
pthread_spin_lock(&myq.spin);
myq.tail->next = new;
new->next = 0;
myq.tail= next;
if(!myq.head)myq.head = new;
pthread_spin_unlock(&myq.spin);
Worst case delay for higher priority task is small and easily
calculated.
I'm preparing a cookbook of such methods in a new paper.
>
> > And, yes, it does make the system slower even when not using it, for
> > several reasons - mentioned in the paper. As one example, all your
> > wait queues need to be atomically re-orderable.
>
> I know too little of the implementation to verify this, but if it is true,
> than that is a good argument against priority inheritance.
Think about what happens as you pass inherited priority down a chain
of blocked tasks:
if High blocks on m1 which is help by T1 which is blocked
on m2 .... down to m_n.
High must promote the priority of every task T1 .. Tn and each one
is on a wait queue that may be priority ordered!
>
> --martijn
>
>
>
>
> Powered by ASHosting
--
---------------------------------------------------------
Victor Yodaiken
Finite State Machine Labs: The RTLinux Company.
www.fsmlabs.com www.rtlinux.com
