On Sun, 30 Oct 2005 13:36:41 +0100 fons adriaensen <[EMAIL PROTECTED]> wrote:
> This can still be so if the access to the shared data structure is > regulated by the same mutex that protects the condition variable, > provided that the operation on the shared data is very simple and fast. True.. > In libclthreads, the operation performed while the mutex is held is > either incr/decr of a counter, or adding/removing an element at > the end/start of a linked list. Both operations are so trivial > that it would be silly to use a separate mutex for them. > The nice thing about condition variables is that they allow you > to re-use the mutex in this way, and in fact that's why they > exist at all. Yeah, but i figured with RT constrains on the signaller it looked a bit different. Thinking about it a bit more it seems i was wrong :) As in the other case (a data structure where operations carried out by the signallee might take a long time (signaller op naturally needs to be short time RT safe)) there's also nothing gained by seperating the two mutexes. > Thinking a bit further, the conclusion is that the use of lock-free > data structures is warranted only iff the event passing mechanism > is lock-free as well, otherwise nothing is gained. Naturally. > False wakeups are easy to avoid as well in this way. In libclthreads > the sender will only signal the single CV iff the change of state of > the ITC object (all the semas and mailboxes) would trigger some > action in the receiver, i.e. it checks what the receiver is waiting > for. In the other case only the state is updated. Oh i thought i read somewhere that when pthread_cond_wait it is not guaranteed that anyone actually signalled. Will do some more reading. Thanks for your insights, Flo -- Palimm Palimm! http://tapas.affenbande.org