Date: Fri, 18 Oct 2002 11:01:16 -0400 (EDT) From: John Baldwin <jhb@FreeBSD.org> To: Andrew Gallatin <gallatin@cs.duke.edu> Cc: freebsd-smp@FreeBSD.org Subject: RE: MP synchronization rules documentation?? Message-ID: <XFMail.20021018110116.jhb@FreeBSD.org> In-Reply-To: <15790.57869.305296.257633@grasshopper.cs.duke.edu>
index | next in thread | previous in thread | raw e-mail
On 17-Oct-2002 Andrew Gallatin wrote: > John Baldwin writes: > > > > On 17-Oct-2002 Andrew Gallatin wrote: > > > > > > Are the synchronization rules for FreeBSD-current documented anywhere > > > other than mutex(9)? > > > http://people.FreeBSD.org/~jasone/smp/smp_synch_rules.html looks > > > promising, but it seems to be dead. > > > > > > I'm asking because I've just been porting my $day_job's device driver > > > to -current. At first, I thought the synchronization primitives would > > > be a direct port from Solaris, but we (FreeBSD) seem to make a few > > > assumptions that other OSes don't. > > > > > > Are the following assumptions currently true? > > > > > > 1) you cannot sleep holding a mutex, even if you know damned well its safe > > > > It's almost never safe. It would only be safe you are blocked and are > > guaranteed to be awoken in a short period of time. You might want to use > > the mutex to protect a flag or some such. > > Well, its safe for us for just that reason. We lock a resource passed > to our board against access by another process while the device owns > the resource. When the hardware is done with the resource, the > interrupt handler signals the blocked process, which unlocks the > resource (or a timeout expires, the board is marked dead, and the > timeout takes care of signaling the blocked process). It works fine on > Solaris, etc. > > I'm now using a mutex to protect a flag so that I can use a kernel > with INVARIANTS. > > > > 2) you cannot hold any mutex other than Giant if you're holding Giant > > > > This is not true. The only rule with Giant is that if you are going to > > hold Giant, you have to acquire Giant before any other mutexes. Put > > another way: you cannot acquire Giant non-recursively while holding > > another mutex. You may acquire other mutexes while holding Giant, and > > you may acquire Giant recursively while holding other mutexes. > > > OK.. > > > > Are there other assumptions that are not documented in mutex(9)? > > > > Witness should enforce all of them. Hmm, one that it doesn't however: > > > > - Do not hold any mutexes (except for Giant) across copyin(), copyout(), > > uimove(), fuword(), etc. You shouldn't need locks when calling these > > functions anyhow. > > Ugh. Now that I'm just using flags, that's probably not an issue, but > thanks for bringing it up. > > Is this documented anywhere other than by WITNESS? Would you consider > adding this information to mutex(9)? I imagine there may be > some ISV's who look at mutex(9) and condvar(9) and think .. "Ah, just > like Solaris!" (and they're wrong because Solaris lets you sleep). Hmm, well, this is sort of documented because you aren't supposed to hold locks across functions that can sleep and all of those functions can sleep. :) I wouldn't mind this being documented in mutex(9), but it really belongs somewhere else I think. Also, WITNESS doesn't actually test those functions yet. > Dumb question: If you can't sleep while holding a mutex, how do > you aquire 2 sleep mutexes? I guess that must be a special case? > > mtx_lock(a); > mtx_lock(b); <--- could sleep here if b is contested This is not sleeping. Here is the difference: When you sleep via a cv or some such, you don't have a guarantee that you will ever wakeup (well, for ones with timeouts you do but it may be a relatively long time and one shouldn't hold locks for long periods of time). However, if you don't allow mutexes to be held across a sleep, then you know that if you block on a mutex the owner of that mutex will run as soon as it is allowed and will wake you up. Not if it gets woken up, but will (assuming it doesn't have a bug and doesn't ever release the lock). This is a bit stronger assertion and thus blocking on a lock is not the same as sleeping on a tsleep or cv. -- John Baldwin <jhb@FreeBSD.org> <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the messagehelp
Want to link to this message? Use this
URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20021018110116.jhb>