Dayton wrote:
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 destructor. 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.