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

[Sean Kelly]

Steven Schveighoffer wrote:
> "Sean Kelly" wrote
>> Regan Heath wrote:
>>> Does it 'break' the system to allow a thread with a read lock to aquire a 
>>> write lock (assuming we block until no other thread has a read lock)?
>> Some read-write locks allow a read lock to be 'upgraded' to a write lock, 
>> but I never liked the idea.  For one, it complicates the algorithm quite a 
>> bit.
> 
> There is no problem with upgrading, the problem is the assumption that the 
> data has not changed since you have obtained the write lock.  Janice's code 
> is a good example.  Let's say we change it to:
> 
>  class Lookup
>  {
>      shared int[int] map_s;
> 
>      int readonly lookup(int key)
>      {
>          {
>              auto map = readable(map_s);
>              if (key in map) return map[key];
>          //}  no release of readable lock yet.
>          //{
>              auto map = writable(map_s);
>              //if (key in map) return map[key];  // uncomment this for 
> thread safety
>              map[key] = readDataFromFile(key);
>              return map[key];
>          }
>      }
>  }
> 
> 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?  Whoever does, once the first thread has released the lock, the 
> second thread now gets the lock AFTER the data is modified.  There's no way 
> around it.

I think upgradeable read locks only work if the upgrade process can 
fail.  Since two threads hold a read lock in this case, neither thread 
could upgrade to a write lock.  This makes the upgrade process of very 
limited utility IMO, and is another reason why I didn't implement it in 
Tango's ReadWriteLock.


Sean