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


> -----Original Message-----
> From: Ángel González [mailto:keisial@gmail.com]
> 
> 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.

The benchmark has been written by others and I am trying to run it on my
run-time system. The way the benchmark works is that the master thread
acquires locks for each queue and enqueues the work for the worker thread
unlocking the mutex associated with the queue (happens to be the mutex
associated with the condition wait as well). Finally it does a condition
broadcast on the condition variable. I was expecting to see weird data
races, nothing of which was happening. Which is why I resorted to emailing
the list to have a better understanding of how condition signaling is
implemented.

Regards,

Bharath

Attachment: smime.p7s
Description: S/MIME cryptographic signature


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