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

From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-07 08:26:02

Matthew Vogt wrote:
> Michael Glassford <glassfordm <at> hotmail.com> writes:
> 
> 
>>Translating this to the constructor model of promotion would have to 
>>look something like this, I guess:
>>
>>void f(read_write_mutex& m)
>>{
>>     read_write_mutex::try_read_lock r(m);
>>
>>     //do "read stuff"
>>
>>     read_write_mutex::try_write_lock w(r, /*maybe a parameter here to 
>>use try_promote() instead of promote()*/);
>>
>>     if (!w.locked())
>>     {
>>         r.unlock();
>>         w.lock();
>>         //redo some of "read stuff"
>>     }
>>
>>    //do write stuff
>>}
> 
> 
> You could encapsulate some of that in the constructor of the write lock:
> 
> void f(read_write_mutex& m)
> {
>   read_write_mutex::read_lock r(m);
> 
>   do_read_stuff();
> 
>   read_write_mutex::write_lock w(r);  // Upgrade, releasing and re-acquiring
>                                       // if necessary
>   if (!w.atomically_promoted())
>   {
>      do_read_stuff();
>   }
> 
>   do_write_stuff();
> }
> 
> It certainly looks error-prone, by requiring a test and the repetition of the
> earlier code.  Makes you wonder if it should have a function to execute on
> non-atomic upgrade:
> 
> {
>   read_write_mutex::read_lock r(m);
> 
>   do_read_stuff();
> 
>   read_write_mutex::write_lock w(r, bind(this, &class::do_read_stuff));
> 
>   do_write_stuff();
> }
> 
> You could reduce further, but I'm sure it will collapse under the weight of
> real code :)

However, I don't see any way to avoid re-trying after the write-lock is 
obtained when promotion fails, and I don't see a way to prevent 
promotion from failing except for the suggested latent-read-lock / 
upgradeable-read-lock. I agree that such a lock is a good idea, but it 
does have the drawback of serializing all upgradeable read locks, which 
could be quite undesirable in some circumstances.

Mike