VOP_RENAME of the future

[rick at snowhite.cis.uoguelph.ca]

>>     This is a very common mistake, and it's really the fault of the loc=
>kmgr
>>     code, not you.  The original designers of the lockmgr code in their=
>
>>     infinite wisdom made the locking code not retry a blocked lock by=20
>>     default.  It's absolutely the wrong way to do it.  So if you do a=20
>>     lockmgr LK_EXCLUSIVE without LK_RETRY, it will still block, but it =
>
>>     won't retry after it unblocks.
>
>what?  which use could this have, ever?  what happens then when it unbloc=
>ks, will it just sleep or will it fail after the lock becomes free again?=

Although it might not be common, I run into it w.r.t. nfsd threads. There
are N of them and there are times (fortunately infrequent) when I need to
do something with one thread while the rest are blocked. I do this by using
an exclusive lock at a point where they aren't doing an RPC. The trick is
I only want one thread to hold the lock and do this "something", then I
want the rest of the threads to wake up and continue (not needing to take
turns getting an exclusive lock).

I currently use "home grown" code to do this, but it's basically
LK_EXCLUSIVE without LK_RETRY.

So, maybe not common, but sometimes useful? rick