Prev: Is there an IRC channel which talks about driver development?
Next: unique NTFS file ID
From: K�r�at on 24 Jul 2008 08:11
Hi,

In my IOCP based socket server I plan to use Windows Threadpool. My server
will be a switch so it will receive some form of data from a client and
send it to an intended client.

I have constant number of threads for IO completions (IOCP workers). But I
need a real ThreadPool for further processing of messages. So I decide to
use Windows Threadpool API. From my inspections, I have seen that the most
critical issue about Windows Threadpool is deciding "flags" parameter of the
QueueUserWorkItem () function.

My requirements force me to use WT_EXECUTEINIOTHREAD because my worker
threads will post overlapped IOs and shouldn't die before those IOs
complete. MSDN says this flag is not efficient in documentation of
QueueUserWorkItem () function. I know a little about alertable wait and user
APCs but if I use WT_EXECUTEINIOTHREAD the thread pool use those tecniques
to execute my work. My server's efficiency directly depends on the
ThreadPool's efficiency so the question is that is it appropriate to use
Windows ThreadPool in this way? Does it scale well and give igh throughput?

Thanks in advance.


From: K�r�at on 24 Jul 2008 08:59
I learned something new about alertable IO and APC and some new questions
arise :

MSDN says "The callback function is queued as an APC" about
WT_EXECUTEINIOTHREAD flag in documentation QueueUserWorkItem () function. So
the OS creates some threads and put them into alertable wait state and queue
an APC to one of them whenever the QueueUserWorkItem () function gets
called with WT_EXECUTEINIOTHREAD flag. So far so good, but documentation
also says : "this flag should be used only if the callback generates APCs to
the current thread and the APC should be executed after the thread returns
to the thread pool.". The point is that my sockets are associated with an
IOCP which is completely out of the threadpool and I don't specify any
completion routine as I call WSASend() and WSARecv (). So, my callback does
not generate APCs.

Weel, in this case, how an IO-bound thread in the threadpool will know about
completions of pending IOs and decide to die?

Best regards


"K�r�at" <kursattheking(a)gmail.com> wrote in message
news:egBSgZY7IHA.3696(a)TK2MSFTNGP04.phx.gbl...
> Hi,
>
> In my IOCP based socket server I plan to use Windows Threadpool. My server
> will be a switch so it will receive some form of data from a client and
> send it to an intended client.
>
> I have constant number of threads for IO completions (IOCP workers). But
> I need a real ThreadPool for further processing of messages. So I decide
> to use Windows Threadpool API. From my inspections, I have seen that the
> most critical issue about Windows Threadpool is deciding "flags" parameter
> of the QueueUserWorkItem () function.
>
> My requirements force me to use WT_EXECUTEINIOTHREAD because my worker
> threads will post overlapped IOs and shouldn't die before those IOs
> complete. MSDN says this flag is not efficient in documentation of
> QueueUserWorkItem () function. I know a little about alertable wait and
> user APCs but if I use WT_EXECUTEINIOTHREAD the thread pool use those
> tecniques to execute my work. My server's efficiency directly depends on
> the ThreadPool's efficiency so the question is that is it appropriate to
> use Windows ThreadPool in this way? Does it scale well and give igh
> throughput?
>
> Thanks in advance.
>
>


 | 
Pages: 1
Prev: Is there an IRC channel which talks about driver development?
Next: unique NTFS file ID