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

From: Matt Hurd (matt.hurd_at_[hidden])
Date: 2004-07-10 21:38:01

On Sat, 10 Jul 2004 15:51:43 -0400, Howard Hinnant <hinnant_at_[hidden]> wrote:
> On Jul 9, 2004, at 9:47 PM, Matt Hurd wrote:
> 
> > From memory the use case was reading stuff and then if that said I
> > needed to write something, write it by upgrading the lock.
> >
> > However, you are not going to be able to escape the deadlock in this
> > case _ever_.  AFAICT was if two things read concurrently and need to
> > change state, the both can't if the states are dependent and thus you
> > always have a deadlock.
> 
> The upgradable_read_lock, not abused as in the case I showed, will not
> deadlock.  The key (and the restriction) is that only one
> upgradable_read_lock can be active at a time, though it can share with
> any number of read_lock's.  You are right about the 2-read-to-write
> promotion case.  And that is exactly why upgradable_read_lock's are
> exclusive among themselves.  And it is also why you can't "trick" a
> read_lock into a promotion (as my abuse-example showed).
> 
> I believe the upgradable_read_lock is still a viable solution for a
> very special situation, but it requires suitable documentation to guide
> the programmer in how not to abuse it.

OK.  I buy that, but perhaps as a separate mutex beyound the standared
shareable (rw).  I suspect some platforms will support rw_mutex like
behaviour natively without the upradeable part.

The upgradeable shareable lock would work if only one is allowed and
it had priority over blocking exclusive locks to prevent state
invalidation.

It would have to be a special situation where the section of code was
not in high contention due to its lack of concurrency (which would be
the same for an exclusive lock), with reasonable read concurrency
benefits from other sections of code and lowish probability ( at least
less than 100% ;-) ) that an upgrade to exclusive (write) access
should take place.

Does that sound right?  I'm not sure I have that correct.

Struggling for a use case myself, but it doesn't sound improbable.  

Perhaps taking a upgradeable read lock or write lock when the thread
already has a read, or a write lock when the thread has an upgradeable
read lock, should generate an exception, at least in debug mode in
addition to the documentation.  I think rw_mutex already does this for
the read to write from memory.

Regards,

Matt Hurd.