I received a very good review from good friend and former collegue Frank B., and I've taken most of his comments at heart. So here's "Version 2". At this time we're still mailing about the approach, and the (non)elegant parts in it. I'll keep you posted.

I furthermore received comments from Lisa R., which identified a race condition in my original code. Fixed now - thanks Lisa!

Also from Frank, I got very neat code for mutex handling. The code below uses one global variable for locking; Frank's code is way smarter. Check out the new version at the blog entry Mutexes in C++ Threads.

If you want to download the code, get the source file threads.cc. It has all the necessary code in one file.

General approach

The class implements the following member functions:

• A virtual destructor, incase derived classes want to implement their own.
• A member function lock() and unlock(), to "synchronize" thread execution.
• And finally, there's member function run(), which is called to start thread execution. This function returns an ID (of type a pthread_t), so that the starter of the thread can wait for the thread to finish, if they wish so.

A sample MyThread class

class MyThread: public Thread {
public:
    void act();
};

void MyThread::act() {
    for (int i = 0; i < 10; i++) {
	lock();
	cout << "Hello World from thread " << hex << pthread_self()
	     << ", counter is " << i << "\n";
	unlock();
	sleep (1);
    }
}

According to Frank's remarks: I have to admit that lock() and unlock() don't really belong into the Thread class. A separate class Mutex is in real life more appropriate. Please consider my squeezing the locks into Thread as laziness... or "the demo effect"...

How to start MyThread

The caller mustn't delete the thread objects! That is handled entirely within the Thread class. The reason is of course that the threads run separately - the caller doesn't know the right timing to call delete.

(Actually, POSIX threads have a way of "waiting" for a thread to terminate, using pthread_join(). The caller is of course at liberty to use this approach. However, I still chose to implement deallocation entirely within Thread, so that the caller doesn't need to worry. The caller can just "fire and forget". According to Frank, this breaks the rule of thumb "if you pack it in, pack it out yourself". I agree, normally I'd want the one to allocate something to also de-allocate it. This situation breaks that rule...)

Here's the first example. The following main() function fires up two threads, waits 15 seconds, and stops. The necessary waiting is there to let the two threads finish:

void test1() {
    cout << "Starting two threads,\n"
	 << "and sleeping for 15 seconds to allow threads to finish.\n";
    
    // Instantiate two thread objects and fire them up.
    (new MyThread())->run();
    (new MyThread())->run();

    // Wait for the threads to finish.
    sleep (15);
}

Here's the second example. This invocation actually waits for the threads to finish. It involves pthread_join() and is of course more precise than sleeping for 15 seconds.

void test2() {
    cout << "Starting two threads,\n"
	 << "and waiting for them to finish.\n";
    
    // Instantiate two thread objects.
    MyThread
	*a = new MyThread(),
	*b = new MyThread();

    // Start 'em up.
    pthread_t id_a = a->run();
    pthread_t id_b = b->run();

    // Wait for the threads to finish.
    pthread_join (id_a, 0);
    pthread_join (id_b, 0);
}

Class Thread

class Thread {
public:
    virtual ~Thread();				// dtor

    virtual void act() = 0;			// Pure virtual act()

    pthread_t run(bool joinable = true);	// The starter

    void lock();				// Synchronization
    void unlock();
    
private:
    static void *start(void *obj);

    static bool initialized;			// Mutex initialized yet?
    static pthread_mutex_t thread_mutex;	// Mutex itself
};

Trivial Thread member functions

pthread_mutex_t Thread::thread_mutex;
bool Thread::initialized = false;

Thread::~Thread() {
}

void Thread::lock() {
    int res;
    
    if (! initialized) {
	if ( (res = pthread_mutex_init (&thread_mutex, 0)) )
	    throw (static_cast<string>("Failed to initialize static mutex: ") +
		   strerror(res));
	initialized = true;
    }
    if ( (res = pthread_mutex_lock (&thread_mutex)) )
	throw (static_cast<string>("Failed to obtain mutex lock: ") +
	       strerror(res));
}

void Thread::unlock() {
    int res;
    if ( (res = pthread_mutex_unlock (&thread_mutex)) )
	throw (static_cast<string>("Failed to release mutex lock: ") +
	       strerror(res));
}

Thread::run() and Thread::start()

POSIX threads are started using pthread_create(). This C function requires a "thread entry point", which is a pointer to a function that accepts a void* argument, and returns a void*. That's actually the reason that Thread::start() is there, it converts to the right prototype and it's static, hence "object-less".

So first, there's Thread::run(). It has an optional argument bool joinable, default true, which sets the thread's "detach state". The caller can choose to start the threads as either totally detached, or not. When threads are started in detached mode, i.e., not-joinable, then the caller cannot use pthread_join() to wait for a thread to finish.

To be more precise, detached or joinable threads each have advantages and disadvantages:

• When threads are started as joinable, then the caller can wait for them to finish. However, the caller will then have to "remember" what threads were started. These are the ID's returned by run() when starting the threads.
• In my experiments, joinable threads ate more resources. Repetitive calls to pthread_create() would fail. Detached threads didn't; it seems that you can have more of these. But then, joining detached threads isn't possible.

Oh, just one more thing. When a thread is started, then error EAGAIN can be the result. In that case, there are no resources to start the thread at this time. When this happens, run() will wait a second and retry. If this fails three times in a row, then run() gives up.

  
pthread_t Thread::run(bool joinable) {
    pthread_attr_t attr;
    int res;
    pthread_t th;

    if (pthread_attr_init (&attr))
	throw ("Cannot initialize thread attributes");
    if (joinable) {
	if (pthread_attr_setdetachstate (&attr, PTHREAD_CREATE_JOINABLE))
	    throw ("Cannot set thread state as joinable");
    } else {
	if (pthread_attr_setdetachstate (&attr, PTHREAD_CREATE_DETACHED))
	    throw ("Cannot set thread state as detached");
    }
    for (int i = 0; i < 3; i++) {
	res = pthread_create(&th, &attr,
			     reinterpret_cast<void *(*)(void *)>(start),
			     this);
	if (!res) {
	    pthread_attr_destroy(&attr);
	    return (th);
	}
	if (res == EAGAIN) {
	    cout << "Failed to start thread: " << strerror(res) <<
		", retrying\n";
	    sleep(1);
	    continue;
	}
	pthread_attr_destroy (&attr);
	throw (static_cast<string>("Failed to start thread: ") +
	       strerror(res));
    }
    
    throw ("Failed to start thread: "
	   "Resources unavailable after 3 tries, giving up");
}

void *Thread::start(Thread *t) {
    try {
	t->act();
    } catch (string s) {
	cerr << s << "\n";
    } catch (...) {
	cerr << "Thread threw an exception\n";
    }

    // Seppuku
    delete (t);
    return 0;
}

Caveats and Improvements

• Exception handling in the above code is string-based only. After all, it's only a demo. If you want to incorporate this code into your own programs, make sure that the caught exceptions match whatever your program is throwing.
• The code is pretty much tailored to my needs in Crossroads. E.g., the automatic delete in Thread::start() might not be what you desire... A more generic class Thread could make this optional, e.g., using some boolean flag.