Re: [boost] Re: Threads

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.

void
basic_condition::wait()
{
  __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 );
  return;
}

void
basic_condition::notify()
{
  __m->lock(); // lock or block...
  pthread_cond_signal(this->real_cond_t);
  return;
}

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?

  brent

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