[OpenAFS-devel] SOLARIS/osi_vnops.c

[Frank Batschulat]

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 ...

>Delivered-To: openafs-devel@openafs.org
>To: openafs-devel@openafs.org
>From: aeneous@speakeasy.org
>Subject: Re: [OpenAFS-devel] SOLARIS/osi_vnops.c >
>
>I think rw_tryupgrade is supposed to obtain the exclusive lock IFF it can do 
>so without blocking -- in other words, if no race is possible.  Otherwise, it 
>should return failure. 

Thats how it is designed.

> So this AFS_TRYUP routine is saying "yeah, ok, so we 
>couldn't get the upgraded lock without racing.  So what, then, race away."
>
>This is just nuts.  If that's the desired behavior, then why even bother with 
>tryupgrade in the first place?  And I would be very suspicious that permitting 
>this race is acceptable.

I tend to disagree on this:

If you spin on that look ,rather then giving up the read lock
and wait for the write lock, you can get a deadlock with a writer
that has set write wanted bit in the lock at the time 
you hold the read lock. If you now spin with rw_tryenter()
you wont get the write lock because of the other thread which
has set the write wanted bit and can not proceed because you
hold the readlock, needless to say - deadlock.

thats why there is no rw_upgrade(), it's not possible.

  * rw_tryupgrade() has the same failure mode as rw_tryenter() for a 
  * write lock.  Both honor the WRITE_WANTED bit by specification.
 
 

frankB

----------------------------------------------------------
Frank Batschulat, Solaris Kernel Sustaining & Engineering. 

batschul@eng.sun.com	     (+49 30) 747 096 845 (x65845)              
----------------------------------------------------------