Date: Sat, 23 Sep 2000 16:43:07 -0600 From: Chuck Paterson <cp@bsdi.com> To: Bosko Milekic <bmilekic@technokratis.com> Cc: freebsd-net@freebsd.org, freebsd-arch@freebsd.org Subject: Re: mbuf system and SMPng Message-ID: <200009232243.QAA19490@berserker.bsdi.com> In-Reply-To: Your message of "Sat, 23 Sep 2000 14:46:44 EDT." <Pine.BSF.4.21.0009231425080.7679-100000@jehovah.technokratis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Date: Sat, 23 Sep 2000 14:46:44 -0400 From: Bosko Milekic <bmilekic@technokratis.com> To: Chuck Paterson <cp@bsdi.com> Subject: Re: mbuf system and SMPng cc: freebsd-net@FreeBSD.ORG, freebsd-arch@FreeBSD.ORG Bosko Milekic wrote on: Sat, 23 Sep 2000 14:46:44 EDT } Indeed, the lock being released before the asleep() being called in } m_mballoc_wait() is somewhat of a race. I was planning to get rid of the } asleep/await combo anyway (noted in my journal). In fact, MGET() can be } called even with the mutex held, it will just result in recursive } grabbing of the mutex, but it's better to just re-arrange the macro with } a lower-level one, as you say (I noticed BSD/OS does something like } this). } One thing to remember about the recursive stuff is that passing a recursively held mutex to msleep() will not get the mutex released, it will only release it one time. This means that you likely won't be able to get a wakeup. This could be changed, but ->>in general<<- something has gone very wrong if the mutex passed in to msleep() is recursively held. There is likely a layer of code that is expecting that its data is protected, and is not expecting some other process to be able to get at it. Chuck To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200009232243.QAA19490>