How thread-friendly is kevent?
J David
j.david.lists at gmail.com
Sun Nov 9 19:57:06 UTC 2014
How thread-friendly is kevent()?
In most cases, a dedicated thread does the kevent()-ing and
dispatching work to the thread pool, but at extremely high rates that
thread becomes a significant bottleneck.
As an example, consider a pool of, say, 17 threads on a 16 core
machine all in kevent() waiting for one of 32000 open TCP connections
to be read-ready. One connection becomes read-ready. How many
threads will have kevent() return with that event in eventlist? Is
there potential for a thundering herd problem?
Limited small-scale experimentation suggests that only one thread
returns per event, but it's not documented that way, so it's not clear
if that behavior is intended, an implementation detail, or a
coincidence that won't hold up at scale.
Is this behavior at all guaranteed / by design / intentional?
Although it would be ideal if so, it would also make sense to have to
rely on EV_DISPATCH in multithreaded applications to prevent events
from being delivered more than once, or to use EV_ONESHOT and re-add
the event entirely, depending on which approach better suits the
internal data structure the kernel uses for kqueue.
Thanks for any advice!
More information about the freebsd-hackers
mailing list