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