Date: Fri, 22 Oct 2010 21:46:46 +0300 From: Jaakko Heinonen <jh@FreeBSD.org> To: Ivan Voras <ivoras@freebsd.org> Cc: freebsd-geom@freebsd.org Subject: Re: Hyperactive g_event thread Message-ID: <20101022184645.GA1381@a91-153-123-205.elisa-laajakaista.fi> In-Reply-To: <i9rn51$ec0$1@dough.gmane.org> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20101022184645.GA1381>