Thinking In C++. Volume 2: Practical Programming

With the PoolExecutor, you do expensive thread allocation once, up front, and the threads are reused when possible. This saves time because you aren’t constantly paying for thread creation overhead for every single task. Also, in an event-driven system, events that require threads to handle them can be generated as quickly as you want by simply fetching them from the pool. You don’t overrun the available resources because the PoolExecutor uses a bounded number of Thread objects. Thus, although this book will use ThreadedExecutors, consider using PoolExecutors in production code.

A ConcurrentExecutor is like a PoolExecutor with a fixed size of one thread. This is useful for anything you want to run in another thread continually (a long-lived task), such as a task that listens to incoming socket connections. It is also handy for short tasks that you want to run in a thread, for example, small tasks that update a local or remote log, or for an event-dispatching thread.

If more than one task is submitted to a ConcurrentExecutor, each task will run to completion before the next task is begun, all using the same thread. In the following example, you’ll see each task completed, in the order that it was submitted, before the next one is begun. Thus, a ConcurrentExecutor serializes the tasks that are submitted to it.

//: C11:ConcurrentExecutor.cpp

//{L} ZThread

#include "zthread/ConcurrentExecutor.h"

#include "LiftOff.h"

using namespace ZThread;

using namespace std;

int main() {

  try {

    ConcurrentExecutor executor;

    for(int i = 0; i < 5; i++)

      executor.execute(new LiftOff(10, i));

  } catch(Synchronization_Exception& e) {

    cerr << e.what() << endl;

  }

} ///:~

Like a ConcurrentExecutor, a SynchronousExecutor is used when you want only one task at a time to run, serially instead of concurrently. Unlike ConcurrentExecutor, a SynchronousExecutor doesn’t create or manage threads on it own. It uses the thread that submits the task and thus only acts as a focal point for synchronization. If you have n threads submitting tasks to a SynchronousExecutor, those threads are all blocked on execute( ). One by one they will be allowed to continue as the previous tasks in the queue complete, but no two tasks are ever run at once.

For example, suppose you have a number of threads running tasks that use the file system, but you are writing portable code so you don’t want to use flock( ) or another OS-specific call to lock a file. You can run these tasks with a SynchronousExecutor to ensure that only one task at a time is running from any thread. This way, you don’t have to deal with synchronizing on the shared resource (and you won’t clobber the file system in the meantime). A better solution is to actually synchronize on the resource (which you’ll learn about later in this chapter), but a SynchronousExecutor lets you skip the trouble of getting coordinated properly just to prototype something.

//: C11:SynchronousExecutor.cpp

//{L} ZThread

#include "zthread/SynchronousExecutor.h"

#include "LiftOff.h"

using namespace ZThread;

using namespace std;

int main() {

  try {

    SynchronousExecutor executor;

    for(int i = 0; i < 5; i++)

      executor.execute(new LiftOff(10, i));

  } catch(Synchronization_Exception& e) {

    cerr << e.what() << endl;

  }

} ///:~

When you run the program, you’ll see that the tasks are executed in the order they are submitted, and each task runs to completion before the next one starts. What you don’t see is that no new threads are created—the main( ) thread is used for each task, since in this example, that’s the thread that submits all the tasks. Because SynchronousExecutor is primarily for prototyping, you may not use it much in production code.

Yielding

If you know that you’ve accomplished what you need to during one pass through a loop in your run( ) function (most run( ) functions involve a long-running loop), you can give a hint to the thread scheduling mechanism that you’ve done enough and that some other thread might as well have the CPU. This hint (and it is a hint—there’s no guarantee your implementation will listen to it) takes the form of the yield( ) function.

We can make a modified version of the LiftOff examples by yielding after each loop:

//: C11:YieldingTask.cpp

// Suggesting when to switch threads with yield().

//{L} ZThread

#include

#include "zthread/Thread.h"

#include "zthread/ThreadedExecutor.h"

using namespace ZThread;

using namespace std;

class YieldingTask : public Runnable {

  int countDown;

  int id;

public:

  YieldingTask(int ident = 0) : countDown(5), id(ident) {}

  ~YieldingTask() {

    cout << id << " completed" << endl;

  }

  friend ostream&

  operator<<(ostream& os, const YieldingTask& yt) {

    return os << "#" << yt.id << ": " << yt.countDown;

  }

  void run() {

    while(true) {

      cout << *this << endl;