Walter is right about transitive readonly - here's the alternative

[Sean Kelly]

Janice Caron wrote:
> On 9/13/07, Sean Kelly <sean at f4.ca> wrote:
>>> Upgrading just isn't possible in any case - not even in /theory/, let
>>> alone in a given implementation.
>> I'm sure it could be done
> 
> It certainly can't be done atomically...
> 
> Threads 1 and 2 both successfully obtain a read lock.
> Thread 1 attempts to upgrade to a write lock. Since thread 2 has a
> read lock, it waits.
> Thread 2 attempts to upgrade to a write lock. Since thread 1 has a
> read lock, it waits.
> Deadlock.
> 
> 
>> (in fact, POSIX has this feature)
> 
> I wonder how. If it's implemented as release the read lock followed by
> obtain a write lock, then the caller must beware that another thread
> may have written /during/ the upgrade.

If I had to guess, I'd say that the upgrade works by ensuring that 
upgrading readers are given precedence when acquiring a write lock, so 
there is no risk of an external writer acquiring the lock if there are 
any readers in the process of upgrading.  Since the POSIX library is 
already explicitly managing the list of waiters rather than relying on 
someone else's mutex/condvar/semaphore/whatever to do so, the additional 
logic may not be a terrible burden.


Sean