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

[Steven Schveighoffer]

"Steven Schveighoffer" wrote
> There is no problem with upgrading, the problem is the assumption that the 
> data has not changed since you have obtained the write lock.

I have thought of one other problem:

Without remembering which threads have read locks, you can just use a simple 
reference counter to tell if a object is read-locked.

When "upgrading" becomes possible, then you have to know whether the thread 
you are in holds a read-lock or not.  This means you have to store (probably 
in the mutex itself) a list of all threads that hold the read-lock.  Then 
when you go to do the upgrade, it must check to see if the upgrading thread 
is in the list.  This is at least a O(lg(n)) operation, whereas a reference 
counter is a O(1).

BTW I think you could do reentrant read locks (just increment/decrement the 
reference counter one extra time), and write locks could be reentrant (only 
have to store one thread id, you could even use the same reference counter 
as the read locks).

So the only really "bad" situation is:

readable(o);
writable(o);

This really seems awfully scary.  This really could result in an easy 
deadlock, where code that holds a read lock could call code that eventually 
grabs a write-lock.

I'm thinking now that the best thing is just to use read-write locks, unless 
you really know what you are doing, and own all the code that accesses a 
shared object.

I guess I'll cancel my vote for this as a language feature.  Better left as 
a library feature.  Sorry Janice :(

-Steve