On Mon, 12 Jun 2006, Poul-Henning Kamp wrote: > In message <20060612075515.C26634_at_fledge.watson.org>, Robert Watson writes: > >> 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. > > Sounds overly complicated to use. > > Why not just a sx_xlockfast() sx_xunlockfast() ? for some value of "fast" ? At least in the VFS and socket code, you want a notion of acquiring both and dropping one, or upgrading/downgrading. The logic tends to go something like this: SOCKBUF_LOCK(&sb->sb_rcv); /* blah blah blah */ sb_lock(&sb->sb_rcv); /* requires interlock */ /* blah blah blah */ label: /* blah blah blah */ sb_wait(&sb->sb_rcv); /* drop interlock in msleep but keep sleep lock */ /* blah blah blah */ SOCKBUF_UNLOCK(&sb->sb_rcv); so->proto->pru_rcvd(foo); /* drop interlock for layer boundary */ SOCKBUF_LOCK(&sb->sb_rcv); if (!done) goto label; sb_unlock(&sb->sb_rcv); SOCKBUF_UNLOCK(&sb->sb_rcv); I.e., you use the mutex for specific regions, dropping it for layer boundaries and sleeping, but hold the sleep lock for longer periods. Robert N M Watson Computer Laboratory Universty of CambridgeReceived on Mon Jun 12 2006 - 05:08:45 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:57 UTC