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
> / \ [EMAIL PROTECTED]
> ( OZ ) World tour 2000
> ---> X_.---._/ presently in: Perth
> v
Later,
Bosko Milekic
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
