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. BruceReceived on Sat May 17 2003 - 00:41:20 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:37:08 UTC