On Sat, 2005-12-17 at 17:21 -0700, Matthew Wilcox wrote: > On Sat, Dec 17, 2005 at 07:05:21PM -0500, Lee Revell wrote: > > On Sat, 2005-12-17 at 16:43 -0700, Matthew Wilcox wrote: > > > I have a better example of something we currently get wrong that I > > > haven't heard any RT person worry about yet. If two tasks are sleeping > > > on the same semaphore, the one to be woken up will be the first one to > > > wait for it, not the highest-priority task. > > > > > > Obviously, this was introduced by the wake-one semantics. But how to > > > fix it? Should we scan the entire queue looking for the best task to > > > wake? Should we try to maintain the wait list in priority order? Or > > > should we just not care? Should we document that we don't care? ;-) > > > > It's well known that this is a problem: > > > > http://developer.osdl.org/dev/robustmutexes/src/fusyn.hg/Documentation/fusyn/fusyn-why.txt > > Erm. That paper is talking about user-space semaphores based on futexes. > I'm talking about kernel semaphores. At a first glance, fixing futexes > would be a very different job from fixing semaphores. > > BTW, fuqueues? HAHAHAHA. >
Hmm, interesting, so in fact the scheduler does not always run the highest priority runnable process? Do you have a test case where userspace would experience priority inversion due to this? Maybe it has not been a problem as all the PI cases would involve two RT processes that make system calls which end up blocking on a semaphore in the kernel, which is bad RT design anyway - normally you would separate the RT parts of the app which carefully avoid possibly blocking system calls from the non RT parts and communicate via lock free ringbuffers or a similar mechanism. Lee
