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] |
> -----Original Message----- > From: Jonathan Nieder [mailto:jrnieder@gmail.com] > > Hi Bhareth, > > Bharath Ramesh wrote: > > > I am using a benchmark which is associating multiple mutex variables > with a > > single condition variable > [...] > > "The effect of using more than one mutex for concurrent > > pthread_cond_timedwait() or pthread_cond_wait() operations on the > same > > condition variable is undefined; > [...] > > I am wondering if the behavior of the benchmark is correct. > > I would have guessed that any behavior is correct, since the standard > leaves the behavior undefined. What am I missing? 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 pthread_mutex_lock (&mutex); ... ... ... ... pthread_cond_wait (&cond, &mutex); ... ... ... ... pthread_mutex_unlock (&mutex); 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
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] |