Subj : Re: condvar wait / signal on arbitrary object
To   : comp.programming.threads
From : Eric Sosman
Date : Wed Jul 13 2005 11:51 am



Michael B Allen wrote:
> On Tue, 12 Jul 2005 15:09:09 -0400, Eric Sosman wrote:
> 
>>Michael B Allen wrote:
>>
>>>I just had a thought and I'd like your opinion.
>>>
>>>Instead of embedding a condition variable in each object one would want
>>>to wait and signal on, the object could be used as a key to lookup a
>>>condvar by it's address modulo the size of an array of convars. This has
>>>the benifit of permitting one to wait on an arbitrary object (like Java
>>>except you can specify the mutex to unlock). For example:
>>> [...]
>>>What do you think? Good idea or should I not bother?
>>
>>    What problem are you trying to solve?
> 
> No problem in particular. It's just a little be cleaner perhaps. This is
> especially true during development because you're not modify structs and
> their (de)constructors. When you have solidified the object model you can
> then properly refit high-traffic objects with their own condvars. It also
> tests the validity of your condvar conditions with the extra spurious
> wakeups (although I would hardly call that a "feature" :-).
> 
> 
>>    I've seen this technique used in a situation where there
>>were very many very short-lived objects created and destroyed
>>so rapidly that the overhead of pthread_cond_init()/destroy()
>>was undesirable.  (One wonders why these transient objects
>>needed their own private condvars to begin with -- but strange
>>artifacts often creep in when existing single-threaded code is
>>"retrofitted" for multi-threading that wasn't envisioned in the
>>original design.)  The drawback, as you note, is that signals
>>get replaced by broadcasts.
>>
>>    One other thing: Since a condvar can only be associated with
>>one mutex at a time, it'd be an error if two threads used two
>>different mutexes to wait on two different objects that just
>>happened to map to the same condvar.
> 
> 
> Ahh, good point.
> 
> 
>>Perhaps an easy way to
>>dodge this would be to put the mutex in the `struct ctx' and
>>eliminate the `*mutex' argument from both functions.  (In fact,
>>it serves no purpose in ctx_pthread_cond_signal() as things
>>now stand.)
> 
> 
> Or (I'm not certain that this actually makes sense but ...) each condvar
> could have its own mutex.

    That seems to run counter to your "cleaner" goal: it would
require the user of the package to lock the proper mutex, meaning
the caller needs to be aware of the internal mapping between
addresses and mutexes ...  All of a sudden, the fiddly details
of the internals have become part of your API and are leaking
out all over the place.  Plus, as Chris Thomasson points out,
it's a deadlock waiting to happen.  (I guess a deadlocked program
is at least doing no active harm, which is perhaps "cleaner"
than executing buggy code ;-)

    To me, though, the most telling piece of dialogue in this
whole discourse is

>>    What problem are you trying to solve?
>
> No problem in particular.

Permit me to suggest that if you have no problem in mind, you also
have no way to evaluate the goodness or badness of any particular
solution you may come up with.  You've merely found a technological
way to re-frame the famous old riddle:

	"What's the difference between a duck?"

-- 
Eric.Sosman@sun.com

.