Problem - Kevin Tafuro

The proper way to handle a program using an arbitrary number of threads is to generate
a “pool” of threads in advance, which solves two problems. First, it removes
the thread creation time, which can be expensive because of the cost of accepting a
new connection. Second, it prevents system resources from being exhausted because
too many threads have been spawned.
We can effectively map threads that would otherwise be spawned to tasks. Normally
when a thread is spawned, a function to serve as its entry point is specified along
with a pointer to void as an argument that can be any application-specific data to be
passed to the thread’s entry point. We’ll mirror these semantics in our tasks and create
a function, spc_threadpool_schedule( ) to schedule a new task. The task will be
stored at the end of a list so that tasks will be run in the order they are scheduled.
When a new task is scheduled, the system will signal a condition object, which
pooled threads will wait on when they have no tasks to run. Figure 13-1 illustrates
the sequence of events that occurs in each pooled thread.
Notice that the number of tasks that can be scheduled is not restricted. As long as
there is sufficient memory to create a new task structure, tasks will be scheduled.
Depending on how the thread pool is to be used, it may be desirable to limit the
number of tasks that can be scheduled at any one time. For example, in a network
server that schedules each connection as a task, you may want to immediately limit
the number of connections until all of the already scheduled connections have been
run.
#include
#ifndef WIN32
#include
#else
#include
#endif
Task in
queue?
Figure 13-1. Actions carried out by pooled threads
typedef void (*spc_threadpool_fnptr)(void *);
NO
Wait for
task
YES
Run queued
task
Guarding Against Spawning Too Many Threads | 719
This is the Title of the Book, eMatter Edition
Copyright © 2007 O’Reilly & Associates, Inc. All rights reserved.