VOP_RENAME of the future

[rick@xxxxxxxxxxxxxxxxxxxxxxxx]

>    If all the nfsd's held a LK_SHARED lock while running an RPC and
>    released the shared lock while not, then some other thread could
>    obtain an exclusive lock to create a synchronization point, then
>    simply release the lock to allow the other threads to resume.
Yep, that works, so long as the blocked requestor for the exclusive lock
gets priority over new LK_SHARED requests. (Otherwise the one trying to
get the exclusive lock might wait a very long time as the various nfsd
threads grab RPC requests off the rcv queue and re-acquire a shared lock.
aka starvation)

>    Using LK_RETRY for one exclusive lock and not using it for the others
>    wouldn't really give you a synchronization point because you would
>    have no real control over who actually got the lock (so you could still
>    create a cascade of exclusive lock holders, even without LK_RETRY), nor
>    would you be able to ensure that all the other threads were actually
>    in a quiescent state.
I would have probably coded it without LK_RETRY, but in a loop until one
returned successfully. That one would have done the "something" (putting
an NFSv4 state record on stable storage for recovery, it so happens) then
released the lock. The others try and get a shared lock, once the
"something" has been started.

Not a common situation and not one probably worth supporting in
a generic lock mechanism, since it can be built around whatever is provided.
(I also don't know the semantics of LK_xxx well enough to know if this is
 workable, anyhow:-)

rick