I had a problem described here, and I was suggested to use IO completion ports or thread pool.
I have implemented IO completion, calling PostQueuedCompletionStatus to enqueue the task and GetQueuedCompletionStatus to get the next task to execute it. I am using IO completion port as a multi-producer/multi-consumer thread-safe FIFO container without explicit locks. This makes me have full control over the threads, because I may need to terminate the ones process for a long time and report them. Also GetQueuedCompletionStatus waits the calling thread if there is no task left.
Aside from the termination, thread pool suits my needs: my tasks are completed less than a millisecond, but there are lots of them. Also calling QueueUserWorkItem and letting the OS do the synchronizations and executions is simpler.
Are there any differences between two approaches performance-wise? Any comments about my implementation?
Completion Ports are designed to avoid unnecessary context switching. When your thread that is calling GetQueuedCompletionStatus is done processing a work item, it can call right back to GetQueuedCompletionStatus to continue to get more work within its current CPU timeslice.
@Jonathan – If you have blocking calls, then those should pretty much never be made on a thread pulling work items. They should either be performed async (with a Begin/End or *Async call) or block on another thread (worker thread pool). This will ensure that all of your threads servicing the completion port are actually doing work instead of wasting time blocking when other work items are available.
A slight clarification: if you are managing your own threads and calling GetQueuedCompletionStatus, then you have created your own completion port separate from the IO completion port and associated thread pool used by the OS for async IO calls.