FILEDESC_LOCK() implementation
Robert Watson
rwatson at FreeBSD.org
Mon Jun 12 06:59:16 UTC 2006
On Mon, 12 Jun 2006, Poul-Henning Kamp wrote:
> In message <20060612054115.GA42379 at xor.obsecurity.org>, Kris Kennaway writes:
>
>> I wonder if something better can be done with the funky home-grown locking
>> in FILEDESC_LOCK() (see <sys/filedesc.h>) to make it more light-weight?
>
> It probably can.
>
> What's needed is a combined short/long lock, where you can either grab lock
> for sleepable locking (like for instance sxlocks) or only grab a quick
> version (like a mutex) for lightweight operations.
There are a number of places where we interlock a sleep lock and a mutex:
- File descriptors
- Socket buffer sleep locks
- Vnode sleep locks
What we probably want is an sx_init_interlock() that allows us to provide the
interlock for an sx lock, wich some variations on sx_*lock() to say we already
hold the interlock. WITNESS will need some work to be happy with this. I'm
not sure it's possible or desirable to get rid of the above sleep/mutex
interlocks, since they're very much a defined part of the semantic. With
socket buffers, for example, the mutex/interlock is used for data structure
consistency, and the sleep lock is used to prevent interleaving of I/O
operations. Separating the two locks entirely would significantly increase
overhead, and they can't be combined as there are times when user threads are
blocked from simultaneous I/O by the sleepable portion of the lock, but the
stack needs to update the data structures (i.e., when a non-interleaved socket
read is ocurring, and the stack needs to insert data into the buffer to be
read). As things like this are a common idiom, supporting them better with
our primitives makes some amount of sense. Whether things are sufficiently
common to do this, only experimentation will tell. We don't want to end up
with another lockmgr...
Robert N M Watson
Computer Laboratory
Universty of Cambridge
More information about the freebsd-current
mailing list