Date: Sat, 23 Sep 2000 01:31:45 -0400 (EDT) From: Bosko Milekic <bmilekic@technokratis.com> To: Julian Elischer <julian@elischer.org> Cc: current@FreeBSD.ORG Subject: Re: Locking doc.? Message-ID: <Pine.BSF.4.21.0009230115260.2126-100000@jehovah.technokratis.com> In-Reply-To: <39CC37D4.167EB0E7@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 22 Sep 2000, Julian Elischer wrote: > Throwing a lock in every structure is > one > thing but then to tie the whole bundle up together is a completely > different ballgame. Yes, that's the hard part. It can be potentially dangerous to, for example, call the mbuf resource allocation code, while holding a mutex, and with M_WAIT. If the call goes in with M_DONTWAIT, then, theoretically, we shouldn't be blocking, so it's not so much of a big deal. However, for now, if you call with M_WAIT, you better make sure that you're not holding any mutexes going in. According to what I've been able to deduce thus far (and I really haven't looked much yet), BSD/OS seems to do this sort of thing as well (drop a lock on the socket before going in to fetch mbufs with M_WAIT). Their locking in the mbuf system seems less fine-grained than what I have so far (they lock the entire subsystem, effectively, when they're allocating mbufs and mclusters (same lock)). Archie Cobbs recently brought up the idea of writing a mbuf(9) man page which should eventually document, amongst numerous other things, when it's safe to be holding a mutex and when it isn't. As each subsystem will most likely have its own locks, it may be difficult to generalize it all. Bottom line: I do agree that we need such documentation, I just think that's it's difficult to do in a definitive set-in-stone way right now... > -- > __--_|\ Julian Elischer > / \ julian@elischer.org > ( OZ ) World tour 2000 > ---> X_.---._/ presently in: Perth > v Later, Bosko Milekic bmilekic@technokratis.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0009230115260.2126-100000>