Subj : Re: Lock Free -- where to start
To   : comp.programming.threads
From : Sean Kelly
Date : Fri Oct 14 2005 05:21 pm

David Schwartz wrote:
>
>     IOCP doesn't increase software complexity. In fact, in many cases it
> reduces it because the implementation of a thread pool is simpler. Perhaps
> you're subconsciously thinking something like "I have a library that does
> I/O and thread pools and if I want IOCP, I'd have to code it myself". Well,
> once you have a library that does IOCP thread pools and socket I/O, you have
> it forever.

I'm not sure I agree.  Multiplexed I/O typically requires the use of
some sort of state machine, while dedicating a thread to each client is
very straightforward.

>     Consider, for example, a chat server. We have a message we need to send
> to 1,000 clients. If each client has its own thread, we'll need 1,000
> context switches in rapid succession to get all the data sent. If we use a
> thread pool, we'll wind up with one thread on each CPU that will run until
> all 1,000 messages are sent or they use up a full timeslice. As a result,
> we'll need maybe 3 or 4 context switches to get the messages sent instead of
> 1,000.

This is the example I tend to use when thinking about scalable I/O.
One thread per client is definately the easiest to code, though the
options beyond that tend to vary based on the available options.
select() certainly isn't attractive once you're dealing with 1,000
simultaneous connections, but IOCP is no more complex for 1,000
connections than it is for 10.  The only barrier I've found with IOCP
is the complete lack of documentation on it (as of a few years ago at
any rate)--the initial learning curve can be a bit steep.


Sean

.