Re: [boost] Re: 2. It is unavoidable to use threads

From: Carlo Wood (carlo_at_[hidden])
Date: 2004-09-14 05:17:41

On Mon, Sep 13, 2004 at 09:11:46PM -0700, Sean Kelly wrote:
> Sort of.  IOCP (completion ports) requires at least one thread to wait
> on a GetQueuedCompletionStatus call until data is ready to be processed.
> I typically do this with a worker thread or thread pool running in a
> fairly tight loop--data is consumed, broken into messages, and stuck in
> a synchronized queue for further processing by the main thread.  But
> GetQueuedCompletionStatus does allow for a timeout parameter, so that
> worker thread could theoretically be the main thread.  The only risk is
> that a server with a massive number of connections could possibly lose
> data if the worker thread spends too much time doing other things.

Can you explain in detail how it would be possible to lose data?
I understood that when an IO operation finishes, then a 'IO completion
packet' is send to the 'IO completion port' and queued there.
If no thread is currently waiting in GetQueuedCompletionStatus then
still nothing is lost: it will be queued until GetQueuedCompletionStatus
is called again.

The picture I got is this:

There are a number of threads (if you have 4 cpu's then 4 makes sense)
that are all waiting in GetQueuedCompletionStatus.  At one moment some
IO operation that was requested before by any thread completes and
that fact is send to the IO completion port.  The last thread that
entered GetQueuedCompletionStatus will get it (this is so there is
no unncecessary context switching needed: if one thread can keep
up with the completed IO operations then only one thread runs).
Now, if this thread starts handling the IO operation and does not
return to its GetQueuedCompletionStatus before another IO operation
completes, then the next thread starts running etc.  But if there
are no threads waiting, then the completion packet is simply queued.

Sure, if the queue can run full and overflows ... then I guess we'd
lose data - but that just means that the PC can't keep up with processing
the IO using just one cpu.  The user then should have the possibility
to allow using more than one cpu (if he has them).

I find this a rather elegant solution for multi-processor computers.
However, I don't have a multi-processor PC, so I am not insisting on
using IOCP :p

Also, I now understand that this solution is *specifically* MT.
It forces the user to write an MT application because his IO handling
is handled in parallel by more than one thread.  This cannot be
done without that the user is aware of it.  IOCP could be used in
a way that only one thread is actually handling the IO (that is,
calling the 'callback functions' of the user) but then using IOCP
makes no sense.

-- 
Carlo Wood <carlo_at_[hidden]>