Subject: Re: [linux-audio-dev] priority inversion & inheritance
From: Martijn Sipkema (msipkema_AT_sipkema-digital.com)
Date: Thu Jul 11 2002 - 18:43:29 EEST
> 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.
Yes, this is better.
> > > 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!
Actually, if Linux had priority ceiling and spinlocks, I think imight be able
to do without priority inheritance :)
--martijn
Powered by ASHosting
This archive was generated by hypermail 2b28 : Thu Jul 11 2002 - 18:33:15 EEST