> 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
