Date: Fri, 22 Oct 2010 22:31:34 +0200 From: Ivan Voras <ivoras@freebsd.org> To: Jaakko Heinonen <jh@freebsd.org> Cc: freebsd-geom@freebsd.org Subject: Re: Hyperactive g_event thread Message-ID: <AANLkTi=tsj33Wni4iUesMV1_mZn3OevTkS%2BNZj3sw-5v@mail.gmail.com> In-Reply-To: <20101022184645.GA1381@a91-153-123-205.elisa-laajakaista.fi> References: <4C4ED619.7050305@FreeBSD.org> <27237.1280241532@critter.freebsd.dk> <AANLkTi=uRPV2T0=t_1s=Jc4PmBtai=__HqhCtYpiDdTQ@mail.gmail.com> <AANLkTikvV4oymBBA%2B_0zbzd_edS8dRfqqJRODE0989%2Bn@mail.gmail.com> <4C4F171C.9010106@FreeBSD.org> <20101021174301.GA1381@a91-153-123-205.elisa-laajakaista.fi> <i9rn51$ec0$1@dough.gmane.org> <20101022184645.GA1381@a91-153-123-205.elisa-laajakaista.fi>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22 October 2010 20:46, Jaakko Heinonen <jh@freebsd.org> 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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AANLkTi=tsj33Wni4iUesMV1_mZn3OevTkS%2BNZj3sw-5v>