Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 18 Oct 2002 11:22:11 -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:  <15792.10019.102097.885574@grasshopper.cs.duke.edu>
In-Reply-To: <XFMail.20021018110116.jhb@FreeBSD.org>
References:  <15790.57869.305296.257633@grasshopper.cs.duke.edu> <XFMail.20021018110116.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:
 > > 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.

I meant the whole set of rules.    What I'm complaining about is that
as far as I can tell, the rules are not written down anywhere.
This is bad for people trying to port code to -current.

I sent you this from my work address, but freebsd.org had a dns hissy
fit and I doubt you got it, so I'm resending it here.  I don't have a
lot of man page fu, so I may have screwed the formatting.

Drew



Index: mutex.9
===================================================================
RCS file: /home/ncvs/src/share/man/man9/mutex.9,v
retrieving revision 1.32
diff -u -r1.32 mutex.9
--- mutex.9	24 Sep 2002 20:45:58 -0000	1.32
+++ mutex.9	18 Oct 2002 15:20:33 -0000
@@ -457,6 +457,21 @@
 operations.
 This can be used to trim superfluous logging messages for debugging purposes.
 .El
+.Ss Giant
+If you need to acquire Giant, it must be acquired prior to acquiring
+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.
+.Ss Sleeping
+Sleeping while holding a mutex (except for Giant) is almost never safe and
+should be avoided.  There are numerous asserts which will trigger if
+you do this.
+.Ss Functions which can sleep
+Do not hold any mutexes (except for Giant) across functions which
+can sleep, such as copyin(), copyout(), uimove(),
+fuword(), etc.  You shouldn't need locks when calling these functions
+anyhow.
 .Sh SEE ALSO
 .Xr condvar 9 ,
 .Xr msleep 9 ,

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?15792.10019.102097.885574>