On Sun, 30 Oct 2005 13:36:41 +0100
fons adriaensen <fons.adriaensen@email-addr-hidden> 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.orgReceived on Sun Oct 30 16:15:07 2005
This archive was generated by hypermail 2.1.8 : Sun Oct 30 2005 - 16:15:08 EET