Date: Sat, 17 May 2003 13:07:04 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Bruce Evans <bde@zeta.org.au> Cc: current@FreeBSD.org Subject: Re: CFR: fifo_open()/fifo_close() patch Message-ID: <Pine.NEB.3.96L.1030517110318.42953C-100000@fledge.watson.org> In-Reply-To: <20030517190409.Q15481@gamplex.bde.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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@fledge.watson.org Network Associates Laboratories
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1030517110318.42953C-100000>