Re: Q about pthread condition variable usage - mixing interlocks

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

> Is there ANY situation where, for a given pthread condition variable, that u$

For what value of "legitimate"?

I see no reason why this would/should be forbidden, and, indeed, at
least the 5.2 manpage for pthread_cond_wait seems to imply that it is
permitted, provided the condvar is idle:

     When calling pthread_cond_wait() or pthread_cond_timedwait(), a temporary
     binding is established between the condition variable cond and the mutex
     mutex.

     The same mutex must be held while calling pthread_cond_broadcast() and
     pthread_cond_signal() on cond.  Additionally, the same mutex must be used
     for concurrent calls to pthread_cond_wait() and pthread_cond_timedwait().
     Only when a condition variable is known to be quiescent may an applica-
     tion change the mutex associated with it.

I can imagine a situation where, for example, you have many different
objects (which have a long lifetime but are idle for most of it) and a
pool of condvars, with condvars being taken by objects, used, and
returned to the pool.  If the objects already have mutexes associated
with them, it strikes me as non-insane to use the mutex of the object
with the condvar for the duration of that condvar's association with
that object.

Personally, I would tend to associate a mutex with the condvar instead,
but I don't see anything wrong with associating it with the object,
especially if the object already needs one and mutexes are heavyweight
in a relevant implementation.

I'm curious: why do you care?  If, of course, it's anything you can
talk about.

/~\ The ASCII				  Mouse
\ / Ribbon Campaign
 X  Against HTML		mouse%rodents-montreal.org@localhost
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B