When
a new piece of work is added to the work queue, the event is signaled to turn one of the waiting
threads loose. Implementing a thread pool this way is not efficient and comes with its
problems. For example, things become tricky to handle when all threads are busy and work
items are pushed into the queue, especially if only one thread is allowed to complete one work
item before going back to the waiting queue. If all threads are busy and, say, five work items
are queued in the meantime, the event will be signaled but no threads will be waiting. The first
CHAPTER 13 n THREADING 306
thread back into the waiting queue will get released once it calls WaitOne(), but the others will
not, even though four more work items exist in the queue. One solution to this problem is to
not allow work items to be queued while all of the threads are busy. That??™s not really a solution
because it defers some of the synchronization logic to the thread attempting to queue the
work item by forcing it to do something appropriate in reaction to a failed attempt to queue a
work item. In reality, creating an efficient thread pool is tricky business. Therefore, you should
utilize the ThreadPool class before attempting such a feat. The ???Using the Thread Pool??? section
covers the ThreadPool class in detail.
Pages:
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494