From owner-svn-src-head@FreeBSD.ORG Fri Jun 28 17:38:59 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 67A55AAD; Fri, 28 Jun 2013 17:38:59 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from bigwig.baldwin.cx (bigwig.baldwin.cx [IPv6:2001:470:1f11:75::1]) by mx1.freebsd.org (Postfix) with ESMTP id 4397A1AC3; Fri, 28 Jun 2013 17:38:59 +0000 (UTC) Received: from jhbbsd.localnet (unknown [209.249.190.124]) by bigwig.baldwin.cx (Postfix) with ESMTPSA id 7A82FB94B; Fri, 28 Jun 2013 13:38:58 -0400 (EDT) From: John Baldwin To: Benjamin Kaduk Subject: Re: svn commit: r252346 - head/share/man/man9 Date: Fri, 28 Jun 2013 13:37:32 -0400 User-Agent: KMail/1.13.5 (FreeBSD/8.2-CBSD-20110714-p25; KDE/4.5.5; amd64; ; ) References: <201306281633.r5SGXjFU017827@svn.freebsd.org> In-Reply-To: MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-15" Content-Transfer-Encoding: 7bit Message-Id: <201306281337.33157.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH, not delayed by milter-greylist-4.2.7 (bigwig.baldwin.cx); Fri, 28 Jun 2013 13:38:58 -0400 (EDT) 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:38:59 -0000 On Friday, June 28, 2013 1:08:36 pm Benjamin Kaduk wrote: > > +.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). Hmm, perhaps: To avoid deadlock, a thread that holds a spin mutex must never yield its CPU. ? > I think "complicated both to use and to implement" flows better; in the > present text, "both" is something of an interruption. Yes, "both to" does flow better. > > +Unlike condition variables, > > +arbitrary addresses may be used as wait channels and an dedicated > > > > s/an /a / Agreed. > > +.Ss Bounded vs. Unbounded Sleep > > +A bounded sleep > > +.Pq or blocking > > > > The Pq should probably go before "sleep"? I think not. The root sentence is "A bounded sleep is a sleep where..." If you move the parent you get: "A bounded is a sleep where..." However, the "sleep is a sleep" bit is awkward. Perhaps: "In a bounded sleep (or blocking), the only resource needed..." and then "In an unbounded sleep (often referred to as simply "sleeping"), a thread waits for an external event..." > > +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. Agreed. > Let me know if I should just send a patch off to my mentor for approval. I can review it. -- John Baldwin