From owner-freebsd-geom@FreeBSD.ORG Fri Oct 22 20:57:41 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 60CCF1065670 for ; Fri, 22 Oct 2010 20:57:41 +0000 (UTC) (envelope-from ivoras@gmail.com) Received: from mail-yx0-f182.google.com (mail-yx0-f182.google.com [209.85.213.182]) by mx1.freebsd.org (Postfix) with ESMTP id 14CAB8FC0A for ; Fri, 22 Oct 2010 20:57:40 +0000 (UTC) Received: by yxl31 with SMTP id 31so1045591yxl.13 for ; Fri, 22 Oct 2010 13:57:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type:content-transfer-encoding; bh=rmO7Pld4vD83LHGwJVnMhFND9TzqkpSTM1oad6sepok=; b=wMOfg7a/uKghjXvSHvXdlhhPHCOF+1nc7pjwkl4IjEXbk3z5hkLBdFHPGON6Mh+fUF D1yW75WLLB8JQGwwO6le6EAC6Zi1dsuPsJIDtE/n7AaKHPuNsjfuuuM+Ieif8QfvV0v9 Kozz/6MiQrq2BghQBqNRh04smACnfI4ONmoLQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type :content-transfer-encoding; b=u7Ek1/IfJlurAfZw+Th+PG175HWuVqiazVFpLl52t/k6pQMGBaf/PXpK/Wgbuwggru i/uinj7ThyeyCiamyey/BpPEe9ir43hp3EOxGanTL0slTGCP5Amw4R40NCOwVL7Ffhsz RpeGCbN0sZZdsdwUt7zGX0RCkbadil3ZOdsOo= Received: by 10.229.236.203 with SMTP id kl11mr2727196qcb.204.1287779535574; Fri, 22 Oct 2010 13:32:15 -0700 (PDT) MIME-Version: 1.0 Sender: ivoras@gmail.com Received: by 10.229.80.5 with HTTP; Fri, 22 Oct 2010 13:31:34 -0700 (PDT) In-Reply-To: <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> <20101022184645.GA1381@a91-153-123-205.elisa-laajakaista.fi> From: Ivan Voras Date: Fri, 22 Oct 2010 22:31:34 +0200 X-Google-Sender-Auth: T3ONjzIROGdgD8Y8PmaluIrxSzU Message-ID: To: Jaakko Heinonen Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 20:57:41 -0000 On 22 October 2010 20:46, Jaakko Heinonen wrote: > On 2010-10-22, Ivan Voras wrote: >> Isn't this sequence: >> >> - =C2=A0 =C2=A0 mtx_unlock(&g_eventlock); >> =C2=A0 =C2=A0 =C2=A0 wakeup(&g_wait_event); >> + =C2=A0 =C2=A0 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. I'm also not sure, just wanted to discuss the case. Maybe the condvar(9) API would be better here? (but that is probably out of scope for your patch, I'm just thinking aloud)