• Advertisement

Archived

This topic is now archived and is closed to further replies.

IOCP Question

This topic is 5067 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I have been working with completion ports for a while now, but I still have one nagging question. I am using a machine with 1 CPU for the app I am working on at the moment. The program will therefor tell the IOCP that my desired thread count is 1, while at the same time I create 4 threads to service the port (CPU_COUNT * 2 + 2). That all seems like pretty standard stuff. My question has to do with how the IOCP release threads from the service pool to actually handle incoming data. Scenario: - All threads are blocked on GetQueuedCompletionStatus() - Data arrives - Thread1 released to service data - Thread1 spends a long time servicing data, for whatever reason - More data arrives At this point, will another thread be released to service the data? From what I have read, all I see is that additional threads will be released if thread 1 is "blocked." By blocked, does that mean some sort of synchronous operation (ReadFile/WriteFile/send/recv/WaitFor.../etc)? If Thread1 isnt blocked on any of those functions, will another thread still be released to service the new data? If not, is there a state that I can set to allow other threads to be allowed to service the data? Thanks

Share this post


Link to post
Share on other sites
Advertisement
Guest Anonymous Poster
{keeping with your 4-thread pool example in the following discussion}

Service threads are released to do work in a way that has the least impact on the system. If a data block arrives when thread1 reaches the GetQueued...() call, it is scheduled again to work on the next block. If thread1 has not yet returned to GetQueued...() when the next data block arrives, thread2 is scheduled to service it. If you put counters on each thread, you would observe that thread1 is sollicited far more often than thread4. In fact, the best number of threads is when the last thread in the pool, thread4, is almost never called.

That''s why there is a timeout period in the GetQueued...() call so that it breaks out of the waiting for ''special'' processing such as terminating if there isn''t too much work. Conversely, the last thread in the pool, ''thread4'', can also create yet another thread, ''thread5'', if it is sollicited too often. That''s how you can achieve some form of automated thread count balancing. High-performance systems do this.

Share this post


Link to post
Share on other sites
Ok, that helped clear things up a lot. And the automatic thread count balancing sounds like a cool technique, I''ll try that.

Thanks

Share this post


Link to post
Share on other sites

  • Advertisement