From owner-freebsd-smp@FreeBSD.ORG Mon Jun 14 18:44:25 2004 Return-Path: Delivered-To: freebsd-smp@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 6DB3F16A4CF for ; Mon, 14 Jun 2004 18:44:25 +0000 (GMT) Received: from mail4.speakeasy.net (mail4.speakeasy.net [216.254.0.204]) by mx1.FreeBSD.org (Postfix) with ESMTP id 41C5D43D1D for ; Mon, 14 Jun 2004 18:44:25 +0000 (GMT) (envelope-from jhb@FreeBSD.org) Received: (qmail 4482 invoked from network); 14 Jun 2004 18:43:46 -0000 Received: from dsl027-160-063.atl1.dsl.speakeasy.net (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) encrypted SMTP for ; 14 Jun 2004 18:43:46 -0000 Received: from 10.50.41.233 (gw1.twc.weather.com [216.133.140.1]) by server.baldwin.cx (8.12.11/8.12.11) with ESMTP id i5EIhh3d058089; Mon, 14 Jun 2004 14:43:43 -0400 (EDT) (envelope-from jhb@FreeBSD.org) From: John Baldwin To: freebsd-smp@FreeBSD.org Date: Mon, 14 Jun 2004 14:44:38 -0400 User-Agent: KMail/1.6 References: In-Reply-To: MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200406141444.38269.jhb@FreeBSD.org> X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on server.baldwin.cx cc: John Polstra Subject: Re: Question about cv_signal(9) (never mind) X-BeenThere: freebsd-smp@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: FreeBSD SMP implementation group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Jun 2004 18:44:25 -0000 On Saturday 12 June 2004 08:12 pm, John Polstra wrote: > On 12-Jun-2004 John Polstra wrote: > > [Why does a caller to cv_signal(9) have to hold the associated mutex?] > > Never mind. I understand now. It allows the implementation to > avoid doing any locking internally. That seems perfectly > reasonable, and I withdraw my question. To be honest, it's also largely there to try to keep people from writing code that can lose wakeups. The count optimization came later. If the optimization of dropping the lock is more important and we think that people really won't make the mistake of not using locks when they should to avoid the lost wakeups then we could drop the count optimization and allow cv_signal() to not require the lock perhaps. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve" = http://www.FreeBSD.org