Date: Sat, 17 May 2003 19:41:15 +1000 (EST) From: Bruce Evans <bde@zeta.org.au> To: Don Lewis <truckman@FreeBSD.org> Cc: current@FreeBSD.org Subject: Re: CFR: fifo_open()/fifo_close() patch Message-ID: <20030517190409.Q15481@gamplex.bde.org> In-Reply-To: <200305170740.h4H7e2M7059876@gw.catspoiler.org> References: <200305170740.h4H7e2M7059876@gw.catspoiler.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. Bruce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20030517190409.Q15481>