On Sat, 17 May 2003, Bruce Evans wrote: > On Sat, 17 May 2003, Don Lewis wrote: > > > On 17 May, Bruce Evans wrote: > > > My question is mainly: why do you want or need the extra complexity for > > > using the vnode interlock here? > > > > I want to use the vnode interlock so that I can msleep() on it to avoid > > a race condition. If I rely on the vnode lock to protect fi_readers and > > fi_writers, another thread could sneak in, update them, and call > > wakeup() between the VOP_UNLOCK() call and the tsleep() call, causing > > the thread calling tsleep() to miss the wakeup(). > > I see. > > I now think fifo_close() needs both the vnode lock and the interlock. > Its socantrcvmore() calls should be atomic with decrementing the > reader/writer counts to 0. I think locking them with the interlock > would work, but this depends too much on their internals (not sleeping). > Sorry, I deleted your original patch and don't remember exactly what it > does here. > > NetBSD changed VOP_CLOSE() to "L L L" 4+ years ago. No comment on the remainder, but moving VOP_CLOSE to L L L seems like quite a reasonable direction to me. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects robert_at_fledge.watson.org Network Associates LaboratoriesReceived on Sat May 17 2003 - 08:07:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:08 UTC