Agreed. Your point about the initial cost of obtaining a lock across a NOW is
also a good one.
> The argument for recursive locking is modularity: a function is called, it
> needs a lock, and it is not known whether the lock has been acquired by the
> caller.
Hmm...I would probably label this case as sloppy programming. If the lock is a
prerequisite for the function, then the upper layers should track that state.
But I agree with your later comment that this is not a make or break issue.
> (I am cheating here. To do this cleanly, I need to do more than in my current
> writeup: I also need to support the case where the caller holds a read lock
> and the callee requires a write lock. Thus, a read lock can be promoted to a
> write lock, and when such promoted write lock is freed, it reverts to a read
> lock.)
Is this really the best solution? If fairness is important, then one might
imagine a queue of processes that are all waiting to obtain a write lock while
another process holds a read lock. It seems unfair for that process to upgrade
itself to a read lock immediately, perhaps it should be forced to release the
read lock and then obtain the write lock seperately?
The other direction, though, does seem logical; having a write lock and
"downgrading" to a read lock would probably be a useful single-function
operation to have.
-- Eric Salo Silicon Graphics Inc. "Do you know what the (415)933-2998 2011 N. Shoreline Blvd, 8U-808 last Xon said, just salo@sgi.com Mountain View, CA 94043-1389 before he died?"