From owner-freebsd-geom@FreeBSD.ORG Fri Oct 22 18:46:52 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 223D11065674 for ; Fri, 22 Oct 2010 18:46:52 +0000 (UTC) (envelope-from jh@FreeBSD.org) Received: from gw02.mail.saunalahti.fi (gw02.mail.saunalahti.fi [195.197.172.116]) by mx1.freebsd.org (Postfix) with ESMTP id CCEBF8FC17 for ; Fri, 22 Oct 2010 18:46:51 +0000 (UTC) Received: from a91-153-123-205.elisa-laajakaista.fi (a91-153-123-205.elisa-laajakaista.fi [91.153.123.205]) by gw02.mail.saunalahti.fi (Postfix) with SMTP id 20E9413956A; Fri, 22 Oct 2010 21:46:48 +0300 (EEST) Date: Fri, 22 Oct 2010 21:46:46 +0300 From: Jaakko Heinonen To: Ivan Voras Message-ID: <20101022184645.GA1381@a91-153-123-205.elisa-laajakaista.fi> References: <4C4ED619.7050305@FreeBSD.org> <27237.1280241532@critter.freebsd.dk> <4C4F171C.9010106@FreeBSD.org> <20101021174301.GA1381@a91-153-123-205.elisa-laajakaista.fi> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Cc: 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 18:46:52 -0000 On 2010-10-22, Ivan Voras wrote: > Isn't this sequence: > > - mtx_unlock(&g_eventlock); > wakeup(&g_wait_event); > + mtx_unlock(&g_eventlock); > > 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. As far as I have understood this is the normal way to protect against losing wakeups, no? wakeup(9) marks the sleeping process runnable and removes it from the sleep queue but doesn't force a context switch immediately. Thus increased lock contention would happen only if a context switch happens between wakeup() and mtx_unlock(). I don't see this a problem but please correct me if I am wrong. -- Jaakko