Subj : Re: Lock Free -- where to start
To   : comp.programming.threads
From : David Schwartz
Date : Fri Oct 14 2005 09:25 pm


"Sean Kelly" <sean@f4.ca> wrote in message 
news:1129332081.168592.59040@o13g2000cwo.googlegroups.com...

> 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.

    Even if you dedicate a thread to each client, you still need some sort 
of state machine. I can't see how you can avoid it. Doesn't each client have 
to be in a state and perform processing appropriate for that state? What 
about when an administrator wants to know what state every connected client 
is in? What about when you need to check all authenticated connections and 
disconnect any that authenticated with a particular credential?

>>     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.

    One thread per client is the easiest to code if you already have a 
library that provides that. IOCP is just as easy if you start with a library 
that provides that. You write this kind of code just once and use it 
hundreds of times. A tiny bit of extra complexity is utterly irrelevent.

    DS

.