Re: NIO multiplexing + thread pooling
On 09/28/2011 05:20 PM, markspace wrote:
On 9/27/2011 11:21 PM, Robert Klemme wrote:
Because you reduce synchronization overhead. If you have 1 or X threads
doing the selecting and distributing the work over M >> X handler
threads for N >> M channels then you have much higher potential for
collisions than if you have X * (1 selector for M/X handler threads).
Really? Is synchronization, relative to an app that's doing network IO,
a serious concern? I can't imagine that synchronization overhead is even
within a three orders of magnitude of the IO overhead.
It all depends of course how it's done. But imagine 10,000 open
channels with traffic, 1,000 reader threads and a single thread doing
selecting and dispatching to reader threads. If you do not partition
(and this is the case I was talking about) you probably put something
into a single queue from which those 1,000 reader threads read and the
selector thread is hammering it all the time from the other end. And it
gets worse if the number of channels increases. If OTOH you have a
fixed ratio between channels, selector thread and reader threads you
limit the concurrency on the synchronization point.
Note that poor structuring, like organizing your app such that the whole
thing is serialized on one lock, isn't synchronization over head. It's
just blocked.
Suggest a synchronization mechanism for the use case I described above
(1 selector, 10,000 channels, 1,000 readers) and then we can talk about
properties of that.
Kind regards
robert