Re: Locking doc.?
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
Re: Locking doc.?
Bosko Milekic wrote: > > I don't believe so. There are several external resources, such as > on-line papers, and so on. There is also a man page (which I've found > from jasone's web space) which has been prepared by Sheldon Hearn and > which should be at ~jake/mutex.9 > As far "standard way to do it" documents - I haven't seen any and I'm > not sure how worthwile it would be to do this at this point in time, as > the code is still quite dynamic. > (Of course, I'm not implying "don't do it," just "be careful when you > do it" What I'm looking for is something that says for example, what stategy should be used for deadlock avoidance. For example. "Order of locking should be proc then vnode then socket then mbuf", or "Use asleep() await() to back out when encountering a locked item that stays locked for more than xx uSecs." At the moment there is no guide as to how one should combine locks in various different subsystems. Throwing a lock in every structure is one thing but then to tie the whole bundle up together is a completely different ballgame. -- __--_|\ Julian Elischer / \ [EMAIL PROTECTED] ( OZ) World tour 2000 ---> X_.---._/ presently in: Perth v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Locking doc.?
I don't believe so. There are several external resources, such as on-line papers, and so on. There is also a man page (which I've found from jasone's web space) which has been prepared by Sheldon Hearn and which should be at ~jake/mutex.9 As far "standard way to do it" documents - I haven't seen any and I'm not sure how worthwile it would be to do this at this point in time, as the code is still quite dynamic. (Of course, I'm not implying "don't do it," just "be careful when you do it") On Fri, 22 Sep 2000, Julian Elischer wrote: > Do we have a document that descibes in great detail the > locking policy that the SMPng code should follow? > > I've seen several descriptionms as to how it might be done, > but I haven't seen a "Ok we've decided that this is the strategy > we are using" document. > > -- > __--_|\ Julian Elischer > / \ [EMAIL PROTECTED] > ( OZ) World tour 2000 > ---> X_.---._/ presently in: Perth > v Bosko Milekic [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Locking doc.?
On Friday, 22 September 2000 at 19:50:11 -0700, Julian Elischer wrote: > Do we have a document that descibes in great detail the > locking policy that the SMPng code should follow? > > I've seen several descriptionms as to how it might be done, > but I haven't seen a "Ok we've decided that this is the strategy > we are using" document. I haven't seen one either. On the one hand it might be a little early to come up with a (restrictive) policy document, but I do think we should be discussing more actively how we go about subdividing the locking. There's been plenty of experience in the past to show that it's madness to just go about subdividing locks. Greg -- Finger [EMAIL PROTECTED] for PGP public key See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
