Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.java.programmer > #8390
| From | Robert Klemme <shortcutter@googlemail.com> |
|---|---|
| Newsgroups | comp.lang.java.programmer |
| Subject | Re: NIO multiplexing + thread pooling |
| Date | 2011-09-28 18:56 +0200 |
| Message-ID | <9eh1tlFe7hU1@mid.individual.net> (permalink) |
| References | (1 earlier) <alpine.DEB.2.00.1109242028540.12593@urchin.earth.li> <9e8aqfFnorU1@mid.individual.net> <alpine.DEB.2.00.1109272044210.14737@urchin.earth.li> <9efsnrFoviU1@mid.individual.net> <j5vdvo$kon$1@dont-email.me> |
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
Back to comp.lang.java.programmer | Previous | Next — Previous in thread | Next in thread | Find similar
NIO multiplexing + thread pooling Giovanni Azua <bravegag@hotmail.com> - 2011-09-24 20:32 +0200
Re: NIO multiplexing + thread pooling Tom Anderson <twic@urchin.earth.li> - 2011-09-24 20:46 +0100
Re: NIO multiplexing + thread pooling Giovanni Azua <bravegag@hotmail.com> - 2011-09-24 23:09 +0200
Re: NIO multiplexing + thread pooling Robert Klemme <shortcutter@googlemail.com> - 2011-09-25 11:33 +0200
Re: NIO multiplexing + thread pooling Tom Anderson <twic@urchin.earth.li> - 2011-09-27 20:52 +0100
Re: NIO multiplexing + thread pooling Robert Klemme <shortcutter@googlemail.com> - 2011-09-28 08:21 +0200
Re: NIO multiplexing + thread pooling markspace <-@.> - 2011-09-28 08:20 -0700
Re: NIO multiplexing + thread pooling Robert Klemme <shortcutter@googlemail.com> - 2011-09-28 18:56 +0200
Re: NIO multiplexing + thread pooling markspace <-@.> - 2011-09-28 11:07 -0700
Re: NIO multiplexing + thread pooling Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com> - 2011-09-28 17:39 -0700
Re: NIO multiplexing + thread pooling markspace <-@.> - 2011-09-29 09:25 -0700
Re: NIO multiplexing + thread pooling Lew <lewbloch@gmail.com> - 2011-09-30 07:46 -0700
Re: NIO multiplexing + thread pooling markspace <-@.> - 2011-09-30 08:22 -0700
Re: NIO multiplexing + thread pooling Lew <lewbloch@gmail.com> - 2011-09-30 08:30 -0700
Re: NIO multiplexing + thread pooling markspace <-@.> - 2011-09-30 08:49 -0700
Re: NIO multiplexing + thread pooling Robert Klemme <shortcutter@googlemail.com> - 2011-09-30 20:57 +0200
Re: NIO multiplexing + thread pooling "John B. Matthews" <nospam@nospam.invalid> - 2011-09-25 00:26 -0400
Re: NIO multiplexing + thread pooling Giovanni Azua <bravegag@hotmail.com> - 2011-09-25 11:13 +0200
csiph-web