Question

I want to split some CPU intensive jobs to multiple threads. I want to make a thread pool with, let’s say, 4 threads.

I want to know very fast ways to do following:

1. Check if one thread is free for receiving processing
2. Signalize one thread to start specific function
3. Wait for all the threads to finish their jobs

This should be as fast as possible. I use C++ in Visual Studio 2010 on Windows 7. Any Win7/VS2010 specific solution would be preferred if it’s faster than portable approach.

EDIT:
I found on MSDN this sample:

http://msdn.microsoft.com/en-us/library/windows/desktop/ms686946(v=vs.85).aspx

Is there any faster way to do this?

Answer 1

The stuff from the Boost thread library is pretty fast. You can start 4 threads that end up waiting for a boost::condition_variable. In the main thread you can add stuff to a task-queue and then call boost::condition_variable::notify_one in order to start one free thread, if any. As soon as one of the working threads is notified, it takes stuff out of the task queue and continues to do so until the queue is empty. In order to wait for the task queue to finish, let the thread that makes the task queue empty call boost::condition_variable::notify_all and wait in the main thread for that signal. Obviously you need to protect the shared data for this stuff with a mutex.

This technique works fine if you have medium to large size tasks and several thousand or less should execute in a second. I don’t have experience with smaller tasks using this technique.

The parallel patterns library (PPL) is really good at that stuff too, it does a lot of stuff for you, but you don’t have as much control. It’s Windows only, but that seems to be fine with you. 😉

---

EDIT: Your link seems to be a good solution. Using the WINAPI is often the fastest thing you can do, since other APIs are usually build upon it. The WINAPI does not, however, provide very good abstraction. Thus I would prefer PPL, futures, etc. to perform tasks like that. How big are your tasks? If they take more than a few milliseconds, then you shouldn’t worry about the api you’re using, since that’s not the bottleneck.