From: Michael Glassford (glassfordm_at_[hidden])
Date: 2004-07-05 20:49:31
Matthew Vogt wrote:
> Howard Hinnant <hinnant <at> twcny.rr.com> writes:
>>My take, depending upon how the w(r) constructor is implemented, is
>>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.
I agree. That's why I've so far only provided the Boost.Threads
read/write lock try_promote() and timed_promote() methods (though you
can, of course, get the latter to deadlock by using infinite times), and
no promote() method. You could make a promote() method that throws if it
can't promote, as you suggest below, but I don't like the idea much.
>>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:
>>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 (...)
>> 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.
I agree. If releasing and reacquiring is good enough (and it probably is
in many or even most cases), then of course you can do that, but it
isn't really lock promotion.
> 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.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk