On Sat, Aug 06, 2005 at 10:03:36 +0100, Tristan Wibberley wrote: > Jan Hudec wrote: > > On Fri, Aug 05, 2005 at 19:35:14 +0100, Tristan Wibberley wrote: > > > >>I wrote: > >> > >> > >>>There is also Ingo Molnar's (and probably others') RT-PREEMPT patches > >>>currenty under development. These really do try to get nearly every > >>>point preemtible. Drivers should synchronise with semaphores, mutexes > >>>(which both do priority inheritance), and completions. > >> > >>I think that's a bit wrong. It doesn't make sense for a semaphore to do > >>priority inheritance as the whole point of a semaphore is that things > >>are supposed to receive notification when something has finished, and > >>the thing that does the notifying does not try to make progress for the > >>waiters. While a mutex identifies a critical section and the > >>process/thread holding the mutex moves out of the way quickly when a > >>high priority thread/process is waiting (essentially starts making rapid > >>progress for the benefit of the waiter, since the waiter has important > >>things to do). > > > > > > In kernel there is NO PRIMITIVE CALLED MUTEX. It is a special case of > > semaphore. Thus it is the semaphore that has to do priority inheritance. > > In CS, a mutex is *not* a special case of semaphore. A semaphore can Damn I am *NOT* talking about CS. I am talking about LINUX KERNEL. And in Linux kernel a mutex *IS* a special case of semaphore. > sensibly be started at zero, then be upped to indicate there is > something to process. If a high priority thread tries to down a Saying that semaphore *can* do something does not exclude anything being a special case of semaphore. A special case does not use everything the generic thing can do. By the way, this is how completions are used. Completion is in fact a semaphore (in CS sense) too and is meant to be used this way. > semaphore that is at zero, there is no thread that it is waiting for to > get out of the way. A mutex is different, and Ingo's patch adds such a > primitive. I think Ingo's patch has a PI semaphore (the rw-semaphore), I have not read the patch, so I can't argue here. I can only talk about current kernel. In current kernel, a thing called "semaphore" is used, almost exclusively, for mutual exclusion, while a thing called "completion" (which is also a semaphore in CS sense AFAIK) is used for the other things normally done with a semaphore. > but it is limited to behaving and being used like a rw-mutex and is a > bit of a misnomer. The rw-semaphore no longer permits multiple readers > (to ensure fairness and make PI behave better - and even make sense). Kernel already has something called "rw-semaphore" for quite some time. It has really always been only a mutex in the CS sense, because in CS, read-write semaphore does not make sense. > > There are also spin-locks, which are conceptually mutexes, but they > > are special in that they disable preemption -- the real-time patches > > need to reduce the span of these. > > I thought the realtime preempt patch made them preemptible, so they'll > spin when the lock is held on another CPU, but if a higher priority > process on the local CPU becomes runnable, the spinner will have to wait. As I said, I have not read the patch. It presumably involves quite some trickery, but the normal preempt patch already did. > > Notifications when something is finished are usually sent using > > wait-queues (which are "conditional variables") and completions (which > > are rather similar to semaphores). > > I think semaphores use wait queues for their implementation in the > rt-preempt patch. I thought the standard kernel doesn't have > completions, but uses semaphores to approximate them, and that > rt-preempt adds them. Both semaphores and completions always used wait-queues for their implementations. Wait-queues in kernel are not full conditional variables in the CS sense, but rather an underlying thing below all these three. That is because instead of using mutex around them (like CS conditional variables), they use ordering. wait_event() used to be pretty trivial before preempt patch came around, and even after that it does not take a mutex. Normal kernel has completions for quite some time (2.4 definitely had them), they don't share implementation with "semaphores", but are conceptually semaphores and their main difference from "semaphores" is their call complete_and_exit(), which does "up" and terminates a process, which is necessary to synchronize kernel thread termination upon module removal. ------------------------------------------------------------------------------- Jan 'Bulb' Hudec <bulb@xxxxxx>
Attachment:
signature.asc
Description: Digital signature
