Re: VOP_RENAME of the future

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

: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

    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.

    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.

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>