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

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-06-29 11:30:47

Doug Gregor wrote:
> On Tuesday 29 June 2004 10:55 am, Michael Glassford wrote:
> 
>>Doug Gregor wrote:

[snip]

>>>>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. 

I suppose it could, but if you needed to promote and demote a lock a 
couple of times it could get messy; and if you needed to promote 
conditionally, it could also get messy.

Also, you could end up with some interesting situations like this:

     void f(read_write_mutex m)
     {
         read_write_mutex::read_lock r(m);
         if (...)
         {
             read_write_mutex::write_lock w(r); //lock promotion
             //...
         }
         //Point A
     }

The most obvious implementation of promotion would be for the write lock 
to unlock the read lock if promotion succeeded, but leave it locked if 
promotion failed. But in the above code, this would mean that if 
promotion succeeds, neither lock will be locked at "Point A"; however if 
promotion fails, r will still be read-locked at point A.

Another possibility is to define separate read_lock, write_lock, and 
read_write_lock classes, and only the last would allow promotion & 
demotion. The disadvantage of this is a proliferation of lock classes, 
but it may be the best option, all things considered.

Mike