Path: csiph.com!x330-a1.tempe.blueboxinc.net!newsfeed.hal-mli.net!feeder1.hal-mli.net!border3.nntp.dca.giganews.com!Xl.tags.giganews.com!border1.nntp.dca.giganews.com!nntp.giganews.com!local2.nntp.dca.giganews.com!nntp.posted.palinacquisition!news.posted.palinacquisition.POSTED!not-for-mail
NNTP-Posting-Date: Wed, 28 Sep 2011 19:39:48 -0500
Date: Wed, 28 Sep 2011 17:39:47 -0700
From: Peter Duniho <NpOeStPeAdM@NnOwSlPiAnMk.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.5; rv:7.0) Gecko/20110922 Thunderbird/7.0
MIME-Version: 1.0
Newsgroups: comp.lang.java.programmer
Subject: Re: NIO multiplexing + thread pooling
References: <CAA3EEF8.78BF%bravegag@hotmail.com> <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>
In-Reply-To: <j5vdvo$kon$1@dont-email.me>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Message-ID: <FL2dndua_qLJIx7TnZ2dnUVZ_vSdnZ2d@posted.palinacquisition>
Lines: 31
X-Usenet-Provider: http://www.giganews.com
NNTP-Posting-Host: 50.46.118.188
X-Trace: sv3-fAs2Fa8JUkOwD0MyF8Ji/VK46TDMK0+VrKgQeMe6/2y8bzb7+Q7+DSrKJK1wiMeaVTdVrtBxE09FrN+!aUupxg09EGRo5mtFsqU6astfhLzG2gV6zyOk26vXVpEn9EfGR/aWZFNeGRDKACkjw3jOEi6DWIGW!RzmA73VMmI/OkSeziw8QGUWHFowRK52TolZ8oTf0Tf4=
X-Complaints-To: abuse@iinet.com
X-DMCA-Complaints-To: abuse@iinet.com
X-Abuse-and-DMCA-Info: Please be sure to forward a copy of ALL headers
X-Abuse-and-DMCA-Info: Otherwise we will be unable to process your complaint properly
X-Postfilter: 1.3.40
X-Original-Bytes: 3063
Xref: x330-a1.tempe.blueboxinc.net comp.lang.java.programmer:8393

On 9/28/11 8:20 AM, 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).
>
> <http://www.myfacewhen.net/uploads/954-not-sure-if-serious.jpg>
>
> 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. [...]

I don't have specific numbers.  But I can tell you that synchronization 
overhead, and in particular the cost of a thread context switch, is one 
of the reasons that i/o completion ports on Windows is such a critical 
technique for scalable networking processes.

You still get context switches and thread synchronization with IOCP, but 
to a much smaller degree than if a program were structured differently 
(e.g. one dedicated thread per connection).  Using IOCP, one generally 
has a limited number of IOCP threads (proportional to the number of CPU 
cores), and those threads are the only ones that handle actual i/o.

Of course, this has direct implications only for Java running on Windows 
(and unfortunately, negative ones… there's nothing in the standard Java 
implementation for Windows that takes advantage of IOCP).  But similar 
issues might exist on other platforms as well.

Pete