From: Peter Dimov (pdimov_at_[hidden])
Date: 2004-07-27 15:08:39
> Another advantage of modelling a thread as instance of a class rather
> than just a function is that you may elect to implement
> thread-specific variables as thread class members. This works nicely
> if you enforce a
> design rule of a single thread per instance of the Thread class.
The main use of thread-specific storage is to make a library that keeps
global state thread-neutral, giving every thread its own state
(thread-specific free lists in a pool allocator are a good example), or to
decentralize the thread-specific state in several separate modules.
You can execute a Thread class in a boost::thread by using
boost::thread th( boost::bind( &Thread::run, &my_thread_object ) );
but, of course, there are the lifetime issues to consider, which your
proposal does not address, unless you want to enforce join() in the
There is also
boost::shared_ptr<Thread> my_thread_ptr( new MyThread( ... ) );
boost::thread th( boost::bind( &Thread::run, my_thread_ptr ) );
which would automatically keep *my_thread_ptr alive until the thread exits
_and_ you release my_thread_ptr.