Re: FILEDESC_LOCK() implementation

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