DragonFly BSD
DragonFly kernel List (threaded) for 2006-08
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: VOP_RENAME of the future

From: rick@xxxxxxxxxxxxxxxxxxxxxxxx
Date: Tue, 8 Aug 2006 10:41:04 -0400 (EDT)

>>     This is a very common mistake, and it's really the fault of the loc=
>>     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

So, maybe not common, but sometimes useful? rick

[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]