DragonFly kernel List (threaded) for 2006-08
Re: VOP_RENAME of the future
: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.