Re: [boost] Re: Boost.Threads: Do we need all those mutexes?

From: Doug Gregor (dgregor_at_[hidden])
Date: 2004-06-29 10:54:46

On Tuesday 29 June 2004 10:55 am, Michael Glassford wrote:
> Doug Gregor wrote:
> > Right, so what we have (I think) are reasonably well-designed classes
> > with incorrectly specified concepts. scoped_lock should really lock;
> > try_lock should just try to lock.
>
> I'm not sure exactly what you're suggesting here. Are you talking about
> only the constructors, or would you completely eliminate all blocking
> functionality (e.g. the lock() method) from try_lock? And all non-timed
> functionality (e.g. the lock() and try_lock() methods) from timed_lock?

I see that my comment was horribly ambiguous :) Let's try to forget I said it, 
and I'll pipe in elsewhere more clearly with suggestions.

> >>And, if you consider the larger case, which also includes
> >>read/write locks, single-argument constructors are even harder to define
> >>(do the read-lock or write-lock?; do they block or not?).
> >
> > I'd expect scoped_*_read_lock and scoped_*_write_lock classes to be
> > separate classes that model whatever locking concepts we come up with.
> > Actually, the design of the read/write lock on the branch really
> > surprised me, because it used the read_write_lock_state enum instead of
> > distinct types.
>
> There's a lot to be said for separate read-lock and write-lock types,
> and I was hoping to address that at some point; however, it would make
> lock promotion/demotion more difficult (unless maybe the read_lock class
> had a promote() method that returned a write_lock class or something
> like that, but that has some problems, too).

Could write_lock have a constructor/method that takes in the read lock to be 
promoted? I'm a little fuzzy on the implementation issues here. 

        Doug