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

Regan Heath regan at netmail.co.nz
Thu Sep 13 10:45:41 PDT 2007


Janice Caron wrote:
> On 9/13/07, Steven Schveighoffer <schveiguy at yahoo.com> wrote:
>> And you have 2 threads running, both are simultaneously executing this code.
>> If they both have a read lock, and want to upgrade to a write lock, who gets
>> it first?
> 
> A write lock cannot be granted until /all/ read-locks are unlocked. If
> another thread has a read lock, then that thread has a promise that
> the data which the lock protects will not change. That's what a read
> lock /means/. So you cannot "upgrade" a read lock into a write lock,
> for the reason that multiple threads might simultaneously be trying to
> do the same thing, and that would deadlock.

When I made my suggestion I realised you could not upgrade a read lock 
to a write lock until all other read locks were released.  What I didn't 
realise at the time was that waiting for the other read locks to be 
released introduces the possiblity of a deadlock, as you say.

If you take the idea further i.e. You can detect the situation where all 
read locks are held by threads requesting write locks and you can grant 
it to each in turn.

However, that brings you back to the problem that the 2nd, 3rd, nth 
write lock granted in this situation will be writing over data it hasn't 
seen (during it's read lock phase) so the behaviour is likely to be 
incorrect and therefore a 2nd read/check is still required to determine 
the correct action to take.

Regan



More information about the Digitalmars-d mailing list