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