[OpenAFS-devel] SOLARIS/osi_vnops.c

[Jeffrey Hutzelman]

On Thu, 5 Jul 2001, Frank Batschulat wrote:

> There was no question about the lock implementation,
> it was just a question about what AFS complains
> ragrding Solaris rw_tryupgrade() in this 
> particular comment ...

I think AFS expects that if the write lock is possible (i.e. there are no
other readers) but under contention, then rw_tryupgrade will eventually
succeed.  Personally, I don't see how, if called by two threads at the
same time, rw_tryupgrade could possibly succeed - one of them has to give
up the read lock in order for the other to get the write lock.  Perhaps
they expect that rw_tryupgrade will see this and do it; that doesn't seem
like a reasaonable assumption to me.

I haven't read the code to verify this, but one would hope that whoever
wrote the AFS code in question realized that they might have to give up
the read lock in order to get the write lock, and thus the write-locked
portion of the code doesn't depend on any data gathered during the
read-locked portion.  If this is the case, then the AFS_TRYUP that is
there now is perfectly fine, and the call to rw_tryupgrade() is merely an
optimization to avoid yielding.  If not, then AFS_TRYUP is not OK, and I
can think of no possible behaviour of rw_tryupgrade() that would make AFS
happy.


In user mode code that uses LWP (AFS's LWP, which is a non-preemptive
user-mode threading package), this is handled with a new type of lock. 
Such an "upgradeable" lock is compatible with shared locks, but not with
exclusive locks or other upgradeable locks.  It can be atomically upgraded
to an exclusive lock with none of the lossage we've talked about here,
because as long as the upgradeable lock is held, the process holding it is
the _only_ one elegible to get an exclusive lock.

Note that I'm not suggesting that Solaris should provide such a lock type,
but it does have its uses...

-- Jeffrey T. Hutzelman (N3NHS) <jhutz+@cmu.edu>
   Sr. Research Systems Programmer
   School of Computer Science - Research Computing Facility
   Carnegie Mellon University - Pittsburgh, PA