From owner-freebsd-current Fri Sep 22 22:28:10 2000 Delivered-To: freebsd-current@freebsd.org Received: from falla.videotron.net (falla.videotron.net [205.151.222.106]) by hub.freebsd.org (Postfix) with ESMTP id E217037B423 for ; Fri, 22 Sep 2000 22:28:07 -0700 (PDT) Received: from modemcable136.203-201-24.mtl.mc.videotron.ca ([24.201.203.136]) by falla.videotron.net (Sun Internet Mail Server sims.3.5.1999.12.14.10.29.p8) with ESMTP id <0G1B00197R6T21@falla.videotron.net> for current@FreeBSD.ORG; Sat, 23 Sep 2000 01:28:05 -0400 (EDT) Date: Sat, 23 Sep 2000 01:31:45 -0400 (EDT) From: Bosko Milekic Subject: Re: Locking doc.? In-reply-to: <39CC37D4.167EB0E7@elischer.org> To: Julian Elischer Cc: current@FreeBSD.ORG Message-id: MIME-version: 1.0 Content-type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG 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