From owner-svn-src-head@FreeBSD.ORG Fri Jun 28 17:08:38 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id 1566D220; Fri, 28 Jun 2013 17:08:38 +0000 (UTC) (envelope-from bjkfbsd@gmail.com) Received: from mail-qc0-x234.google.com (mail-qc0-x234.google.com [IPv6:2607:f8b0:400d:c01::234]) by mx1.freebsd.org (Postfix) with ESMTP id 99F32194D; Fri, 28 Jun 2013 17:08:37 +0000 (UTC) Received: by mail-qc0-f180.google.com with SMTP id a1so1517143qcx.39 for ; Fri, 28 Jun 2013 10:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=CHEPZFnCCdDUENGiV6Yh11BdIOEkRRZOzIt1ZHGlxaM=; b=wZ4zCrkjp3QUYzJvrcY2N+SBto40DyuJKO2T/+tRWcl3usvg9n9JS5Oqo+39jfyvO2 7377lcbAz04I6Ymx3Y+oDgt4g1fzG3rq2Ltkg6giJ8pHyxl6cm43C8RBJDMp4yRSTXkY VGzEcropdaiK/+Op5uuzKbF1V4l5n7HP3uiG6JEbh5MQ8citNT3U+kP2G9UsWuffVNG8 9hm9uWm0AEiqh9ZBpAKFCq0xepIdKcNVVxebb41DnTM2E+e21CkMHcDImcr3X7Aiw/+i tJLaT1dM0nl569swYFT++5vmJyqHzg86c5nvttm0ntywi5GBOj+fk7QpYDAaCJPujF4V IT6A== MIME-Version: 1.0 X-Received: by 10.229.197.71 with SMTP id ej7mr4352463qcb.27.1372439316314; Fri, 28 Jun 2013 10:08:36 -0700 (PDT) Received: by 10.49.95.202 with HTTP; Fri, 28 Jun 2013 10:08:36 -0700 (PDT) In-Reply-To: <201306281633.r5SGXjFU017827@svn.freebsd.org> References: <201306281633.r5SGXjFU017827@svn.freebsd.org> Date: Fri, 28 Jun 2013 13:08:36 -0400 Message-ID: Subject: Re: svn commit: r252346 - head/share/man/man9 From: Benjamin Kaduk To: John Baldwin Content-Type: text/plain; charset=ISO-8859-1 X-Content-Filtered-By: Mailman/MimeDel 2.1.14 Cc: "svn-src-head@freebsd.org" , "svn-src-all@freebsd.org" , "src-committers@freebsd.org" X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2013 17:08:38 -0000 On Fri, Jun 28, 2013 at 12:33 PM, John Baldwin wrote: > Author: jhb > Date: Fri Jun 28 16:33:45 2013 > New Revision: 252346 > URL: http://svnweb.freebsd.org/changeset/base/252346 > > Log: > Make a pass over this page to correct and clarify a few things as well as > some general word-smithing. > Many thanks for this! A few nits... > Modified: head/share/man/man9/locking.9 > > ============================================================================== > --- head/share/man/man9/locking.9 Fri Jun 28 16:24:14 2013 > (r252345) > +++ head/share/man/man9/locking.9 Fri Jun 28 16:33:45 2013 > (r252346) > -.Ss Spin mutexes > -Spin mutexes are variation of basic mutexes; the main difference between > -the two is that spin mutexes never yield the processor - instead, they > spin, > -waiting for the thread holding the lock, > -(which must be running on another CPU), to release it. > -Spin mutexes disable interrupts while the held so as to not get > pre-empted. > -Since disabling interrupts is expensive, they are also generally slower. > -Spin mutexes should be used only when necessary, e.g. to protect data > shared > +.Ss Spin Mutexes > +Spin mutexes are a variation of basic mutexes; the main difference between > +the two is that spin mutexes never block. > +Instead, they spin while waiting for the lock to be released. > +Note that a thread that holds a spin mutex must never yield its CPU to > +avoid deadlock. > I think this needs a comma after "CPU" (or reordering to emphasize the deadlock avoidance part). > +Unlike ordinary mutexes, spin mutexes disable interrupts when acquired. > +Since disabling interrupts can be expensive, they are generally slower to > +acquire and release. > +Spin mutexes should be used only when absolutely necessary, > +e.g. to protect data shared > with interrupt filter code (see > .Xr bus_setup_intr 9 > -for details). > -.Ss Pool mutexes > -With most synchronization primitives, such as mutexes, programmer must > -provide a piece of allocated memory to hold the primitive. > +for details), > +or for scheduler internals. > [...] > @@ -122,21 +111,41 @@ data structure. > +.Ss Lockmanager locks > +Lockmanager locks are sleepable shared/exclusive locks used mostly in > +.Xr VFS 9 > +.Po > +as a > +.Xr vnode 9 > +lock > +.Pc > +and in the buffer cache > +.Po > +.Xr BUF_LOCK 9 > +.Pc . > +They have features other lock types do not have such as sleep > +timeouts, blocking upgrades, > +writer starvation avoidance, draining, and an interlock mutex, > +but this makes them complicated to both use and implement; > I think "complicated both to use and to implement" flows better; in the present text, "both" is something of an interruption. > +for this reason, they should be avoided. > +.Pp > +See > +.Xr lock 9 > +for details. > @@ -194,7 +181,12 @@ The functions > .Fn wakeup , > and > .Fn wakeup_one > -handle event-based thread blocking. > +also handle event-based thread blocking. > +Unlike condition variables, > +arbitrary addresses may be used as wait channels and an dedicated > s/an /a / > +structure does not need to be allocated. > +However, care must be taken to ensure that wait channel addresses are > +unique to an event. > If a thread must wait for an external event, it is put to sleep by > .Fn tsleep , > .Fn msleep , > @@ -232,122 +225,168 @@ includes the > .Sh INTERACTIONS > -The primitives interact and have a number of rules regarding how > +The primitives can interact and have a number of rules regarding how > they can and can not be combined. > -Many of these rules are checked using the > -.Xr witness 4 > -code. > -.Ss Bounded vs. unbounded sleep > -The following primitives perform bounded sleep: > - mutexes, pool mutexes, reader/writer locks and read-mostly locks. > -.Pp > -The following primitives may perform an unbounded sleep: > -shared/exclusive locks, counting semaphores, condition variables, > sleep/wakeup and lockmanager locks. > -.Pp > +Many of these rules are checked by > +.Xr witness 4 . > +.Ss Bounded vs. Unbounded Sleep > +A bounded sleep > +.Pq or blocking > The Pq should probably go before "sleep"? > +is a sleep where the only resource needed to resume execution of a thread > +is CPU time for the owner of a lock that the thread is waiting to acquire. > +An unbounded sleep > +.Po > +often referred to as simply > +.Dq sleeping > +.Pc > +is a sleep where a thread is waiting for an external event or for a > condition > +to become true. > +In particular, > +since there is always CPU time available, > +a dependency chain of threads in bounded sleeps should always make forward > +progress. > This sentence is a little bit misleading, as the key fact that the threads in question are in bounded sleeps is buried in the last clause. On first reading, one might think that we are still talking about unbounded sleeps, so having CPU time always available is quite the non sequitur. I would reorder things so that "since there is always CPU time available" is last. > +This requires that no thread in a bounded sleep is waiting for a lock held > +by a thread in an unbounded sleep. > +To avoid priority inversions, > +a thread in a bounded sleep lends its priority to the owner of the lock > +that it is waiting for. > Let me know if I should just send a patch off to my mentor for approval. -Ben