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

From: Matthew Vogt (mvogt_at_[hidden])
Date: 2004-07-05 19:27:53

Howard Hinnant <hinnant <at> twcny.rr.com> writes:

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

Yes, there's no point creating a library facility that assists you in writing
code that deadlocks.

> And choice 2 results in the assert(x==y) possibly firing.

I think that in the second case, an exception should be thrown. Typically, if
you fail to promote a rw lock from read to write, then you will have to 
repeat the part of the code that was read-protected after the other thread's
write lock has been released:

bool try_sale(rw_mutex& m)
{
  read_lock rl(m);

  long balance = get_balance();
  long cost = get_total_cost();

  if (balance > cost)
  {
    write_lock wl(rl);

    set_balance(balance - cost);
    // ...
    return true;
  }
  return false
}

bool do_sale(rw_mutex& m)
{
  bool succeeded = false;
  while (true)
  {
    try {
      return try_sale(m);
    catch (rw_promotion_error&) {
      // Try the whole thing again
    }
  }
}

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

But this doesn't achieve anything - if you release the read lock, then you
don't know that what held true while it was read-locked is still true once 
you have acquired a write lock.

If you choose to have lock promotion (having only lock demotion is a viable
choice, except that there will be certain usage patterns that are more
efficient with a fail-able promotion), then it must at least preserve 
known state across promotion.

Matt.