Boost logo

Boost :

From: brent verner (brent_at_[hidden])
Date: 2000-08-18 18:05:34

On 18 Aug 2000 at 21:44 (-0000), William Kempf wrote:
| >
| > I agree with you. CV has a mutex. It would not be that difficult to
| > have two ctors for a CV, would it?
| >
| > basic_mutex* __m;
| > bool __del_m;
| > basic_condition() : __m( new basic_mutex() ) : __del_m(true) { }
| > basic_condition( basic_mutex* m ) : __m( m ) : __del_m(false) { }
| No, this isn't difficult, but it doesn't address the problem. The
| mutex must actually be locked by a thread before it can call wait()
| or notify(). The wait() is the most obvious since it will do an
| unlock/wait/lock operation. Since it's so obvious we immediately
| tried to insure that we were locked at this point by simply passing a
| lock into the wait instead of passing in the mutex.
| The problem is, we also must insure that we're locked on the call to
| notify. This isn't as easy to solve, at least cleanly. Basically,
| the mutex and condition must have a one-to-many relationship (one
| mutex to one or more conditions), so the mutex must be tied to the CV
| at construction. At this time it no longer makes sense to pass a
| lock into wait() since we've already got access to the mutex, though
| we could do this just to insure we're locked at compile time. It
| makes even less sense to pass a lock to notify(), though, since notify
| () won't effect the lock/mutex in any way. Further, passing it in
| like this is now an artificial improvement, since the lock may well
| not be a lock on the specific mutex instance that we're tied to.

  __m->lock(); // calls pthread_mutex_lock( __m->real_mutex_t );
  pthread_cond_wait( this->real_cond_t, __m->real_mutex_t );
  pthread_mutex_unlock( __m->real_mutex_t );

  __m->lock(); // lock or block...

will the above not enforce necessary behavior for wait/notify using
the class sketched above, or am I just failing to see the problem(s)
you are addressing altogether? -- in fact, I'm sure I don't understand
the problem you are trying to solve, could you post a little snippet
of (pseudo)code to demonstrate the situation that presents the great
problem -- if there is already a fair discourse on this, please point
me in its direction.

| Or do we take the pthreads approach and simply have the relationship
| be an artificial one where if you don't follow the rules we simply
| have undefined behavior?

no, you enforce the mutex state relationships _inside_ the condition
class, where the mutex state. if not where is the benefit over using
the system's underlying thread implementation directly?


Damon Brent Verner                        o      _     _         _
Cracker Jack® Surprise Certified  _o     /\_   _ \\o  (_)\__/o  (_)
brent_at_[hidden]                _< \_   _>(_) (_)/<_    \_| \   _|/' \/
brent_at_[hidden]               (_)>(_) (_)        (_)   (_)    (_)'  _\o_

Boost list run by bdawes at, gregod at, cpdaniel at, john at