Path: csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder4.news.weretis.net!news.musoftware.de!wum.musoftware.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail From: Robert Klemme Newsgroups: comp.lang.java.programmer Subject: Re: NIO multiplexing + thread pooling Date: Wed, 28 Sep 2011 18:56:20 +0200 Lines: 33 Message-ID: <9eh1tlFe7hU1@mid.individual.net> References: <9e8aqfFnorU1@mid.individual.net> <9efsnrFoviU1@mid.individual.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: individual.net nVCSdKI2D44sjfVQ0hLq3wYlv2Ffw5cwkCT0TiaBVPDR3M2ik= Cancel-Lock: sha1:/YN8r+yenYwNV3EMYuokRFL9LQI= User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.21) Gecko/20110831 Lightning/1.0b2 Thunderbird/3.1.13 In-Reply-To: Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8390 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