Date: Thu, 17 Oct 2002 12:15:09 -0400 (EDT) From: Andrew Gallatin <gallatin@cs.duke.edu> To: John Baldwin <jhb@FreeBSD.org> Cc: freebsd-smp@FreeBSD.org Subject: RE: MP synchronization rules documentation?? Message-ID: <15790.57869.305296.257633@grasshopper.cs.duke.edu> In-Reply-To: <XFMail.20021017115449.jhb@FreeBSD.org> References: <15790.54204.265656.241333@grasshopper.cs.duke.edu> <XFMail.20021017115449.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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). 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 Thanks, Drew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-smp" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?15790.57869.305296.257633>