From owner-freebsd-geom@FreeBSD.ORG Fri Oct 22 21:03:58 2010 Return-Path: Delivered-To: freebsd-geom@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 311901065696; Fri, 22 Oct 2010 21:03:58 +0000 (UTC) (envelope-from pjd@garage.freebsd.pl) Received: from mail.garage.freebsd.pl (60.wheelsystems.com [83.12.187.60]) by mx1.freebsd.org (Postfix) with ESMTP id C9A308FC1C; Fri, 22 Oct 2010 21:03:57 +0000 (UTC) Received: by mail.garage.freebsd.pl (Postfix, from userid 65534) id 3FDD8456B1; Fri, 22 Oct 2010 23:03:56 +0200 (CEST) Received: from localhost (chello089073192049.chello.pl [89.73.192.49]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.garage.freebsd.pl (Postfix) with ESMTP id 5470845683; Fri, 22 Oct 2010 23:03:50 +0200 (CEST) Date: Fri, 22 Oct 2010 23:03:17 +0200 From: Pawel Jakub Dawidek To: Jaakko Heinonen Message-ID: <20101022210317.GB1742@garage.freebsd.pl> References: <4C4ED619.7050305@FreeBSD.org> <27237.1280241532@critter.freebsd.dk> <4C4F171C.9010106@FreeBSD.org> <20101021174301.GA1381@a91-153-123-205.elisa-laajakaista.fi> <20101022184645.GA1381@a91-153-123-205.elisa-laajakaista.fi> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="2B/JsCI69OhZNC5r" Content-Disposition: inline In-Reply-To: <20101022184645.GA1381@a91-153-123-205.elisa-laajakaista.fi> User-Agent: Mutt/1.4.2.3i X-PGP-Key-URL: http://people.freebsd.org/~pjd/pjd.asc X-OS: FreeBSD 9.0-CURRENT amd64 X-Spam-Checker-Version: SpamAssassin 3.0.4 (2005-06-05) on mail.garage.freebsd.pl X-Spam-Level: X-Spam-Status: No, score=-0.6 required=4.5 tests=BAYES_00,RCVD_IN_SORBS_DUL autolearn=no version=3.0.4 Cc: Ivan Voras , freebsd-geom@freebsd.org Subject: Re: Hyperactive g_event thread X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Oct 2010 21:03:58 -0000 --2B/JsCI69OhZNC5r Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Oct 22, 2010 at 09:46:46PM +0300, Jaakko Heinonen wrote: > On 2010-10-22, Ivan Voras wrote: > > Isn't this sequence: > >=20 > > - mtx_unlock(&g_eventlock); > > wakeup(&g_wait_event); > > + mtx_unlock(&g_eventlock); > >=20 > > too racy? It is possible, especially if something changes in scheduling > > or the wakeup() implementation, and on single-CPU machines, that the > > woken thread could run and then encounter the lock not yet released, > > leading to more lock waiting. >=20 > As far as I have understood this is the normal way to protect against > losing wakeups, no? You won't lose wakeup even if you unlock first and then call wakeup(), but unlocking first might save you a context switch. To avoid wakeup entirely you could remember if the tailq is empty before inserting new element and call wakeup() only if it was empty. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com pjd@FreeBSD.org http://www.FreeBSD.org FreeBSD committer Am I Evil? Yes, I Am! --2B/JsCI69OhZNC5r Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.14 (FreeBSD) iEYEARECAAYFAkzB/BUACgkQForvXbEpPzQe8ACgs+v2R/o/yXorY2oUoQqnercV MJ8AoNQLnBX3fhFDJO+8pU4fABsMmnwT =jpxl -----END PGP SIGNATURE----- --2B/JsCI69OhZNC5r--