This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: pthread_cond_wait with multiple mutex variables


Bharath Ramesh wrote:
> What is confusing to me is that in the man page it states that "condition
> variable becomes bound to a unique mutex when a thread waits on a the
> condition variable". If I have more than one thread waiting of the condition
> variable how does this binding between the condition variable and mutex
> happen. Normally, when one uses condition variable signaling the code would
> like something like
>
>
>
> Now if there is a unique one-to-one binding happening between the condition
> variable and mutex variable then if the behavior is undefined there can be
> incorrect data races because when the condition wait returns I need not be
> holding the mutex lock.
>
> Regards,
>
> Bharath
The normal usage would be to have all threads which are waiting on the cond
variable to use the same mutex. Note that there's no point in having
mutexes if only
one thread uses it. Presumably the thread enqueuing new work is choosing
the right
queue and so it makes sense, does so by holding the lock attached to the
thread
using the quue. It then signals the condition variable awaking every
thread (or so it
tries, since behavior is undefined) so that the one which got the data
added will
process it.
However, all the other threads will be waken up just to sleep again,
since there was no
work for them. So the proper solution would be to have a lock and
condition variable per
thread (= per queue). Only the thread which was sent data is waken up,
and you avoid
relying on undefined behavior.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]