>> 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
