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

From: Howard Hinnant (hinnant_at_[hidden])
Date: 2004-07-05 18:02:27

On Jul 5, 2004, at 5:43 PM, Peter Dimov wrote:

> Howard Hinnant wrote:
>>
>> I'm not following that x==y always holds.  If two threads concurrently
>> hold a read lock, and concurrently try to obtain a write lock, only
>> one thread will get the write lock, the other will block.  Assuming
>> the one thread that got the write lock changes x, then the thread
>> that blocked
>> will fire its assert when it finally unblocks and gets the write lock.
>>
>> What am I missing?
>
> As I understand it, if two threads hold a read lock, no thread can 
> obtain a
> write lock. Write lock == exclusive access. This corresponds to the 
> POSIX
> memory model where write accesses must be exclusive, but read accesses 
> can
> be shared with other read accesses. But I may be wrong. ;-)

So in:

     void f(read_write_mutex m)
     {
         read_write_mutex::read_lock r(m);

             int y = x;

         if (...)
         {
             read_write_mutex::write_lock w(r); //lock promotion

what would happen here if two threads entered f and tried to construct 
w simultaneously?

My take, depending upon how the w(r) constructor is implemented, is 
either:

1.  deadlock.
2.  one thread blocks and one thread gets the lock.

Imho choice 1 is a buggy implementation of the w(r) constructor.  And 
choice 2 results in the assert(x==y) possibly firing.

I believe choice 2 is the only reasonable path.  And I also believe 
that the syntax above might lull a code reader into believing that 
assert(x==y) should always be true.  And therefore I think the 
following (more explicit) syntax is superior:

     void f(read_write_mutex m)
     {
         read_write_mutex::read_lock r(m);

             int y = x;

         if (...)
         {
             r.unlock();
             read_write_mutex::write_lock w(m);

This is essentially how the w(r) ctor must be implemented, if it is to 
be implemented at all.  One could try a try_lock on w if the read count 
is 1, and then fall back on the above if that doesn't work, but I'm 
unsure if that really provides a benefit.

-Howard