Hyperactive g_event thread

Pawel Jakub Dawidek pjd at FreeBSD.org
Fri Oct 22 21:03:58 UTC 2010


On Fri, Oct 22, 2010 at 09:46:46PM +0300, Jaakko Heinonen wrote:
> 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?

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.

-- 
Pawel Jakub Dawidek                       http://www.wheelsystems.com
pjd at FreeBSD.org                           http://www.FreeBSD.org
FreeBSD committer                         Am I Evil? Yes, I Am!
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 196 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-geom/attachments/20101022/cf5c1f46/attachment.pgp


More information about the freebsd-geom mailing list