Boost logo

Boost :

From: William Kempf (sirwillard_at_[hidden])
Date: 2000-08-11 18:03:59

--- In boost_at_[hidden], jsiek_at_l... wrote:
> That's not prohibited, but that is OK. Unless I'm confused, the
> only thing we need to unsure is that the mutex used in the
> wait() is the one that is locked. We don't have to ensure
> a single mutex for the condition varaible (pthreads doesn't).

*pauses to think* I know that pthreads (and most other
implementations) doesn't require this. However, I always thought
that doing so would lead to problems and was generally a design
mistake. I can't think of how it would be now, though, so maybe this
is just hazy paranoia on my part. If no one else knows why I have
this feeling then I guess I'm fine with leaving that part out. It
even looks to me like we've got a very well defined model for all
three types (mutex, condition and lock).

I'd still prefer to call it a mutex and not a monitor (probably
mostly preference here), and I don't want to enforce a need to use
inheritance of the mutex/monitor. Beyond that, I think things look
really good at this point.

BTW, I also think that nesting the condition within the monitor/mutex
is a good idea, since the condition will have to vary it's
implementation according to the type of mutex it cooperates with.

class mutex
   typedef basic_lock<mutex> lock;
   typedef basic_trylock<mutex> trylock;
   typedef basic_timedlock<mutex> timedlock;
   typedef basic_condition<mutex> condition;


mutex mx;
mutex::condition cv;
mutex::lock lock(mx);

while (!full)

Does anyone have further problems with these concepts?

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