Modern C++ Programming with Test-Driven Development

Creating Multiple Threads in the ThreadPool

Is that it? Can we ever know whether we’ve addressed all concurrency holes? To find the remaining problems, one analysis tactic is to think about any “gaps” we have—where we make an assumption about a fact that might no longer be true because of the actions of other obstreperous threads.

The worker function seems to remain the only code with any such potential. In worker, we loop until there is work; each time through the loop establishes and immediately releases a lock within hasWork. Once there is work, the loop exits, and control falls through to the statement pullWork().execute(). What if, during this short span, another thread has grabbed work?

Our ThreadPool currently manages only a single thread, ...