Java’s thread class enforces an interesting pattern and an opportunity to practice the principles of affinity and separation of concerns. Quoting the thread class’ documentation: Essentially, a thread must be a class and conversely a class may have no more than one thread. An argument in favor of one thread per class is a higher likelihood that all of the thread’s operating data is in the class (fairly trivial), and conversely data in the class is closely correlated with its single thread. In the example above, calling start() on a PrimeThread object instance will compute primes larger than the seed prime (minPrime). Compare Java’s threading with C++ or C# where threads are methods. A C++ class that spawns two or more threads will contain data for each thread; e.g. state information, signals and events etc., leading to code that is harder to extend, test and maintain. Here’s a C++ version of PrimeThread that uses _beginthread: Calling start() on a PrimeThread instance will cause the class’ run() function to run in a new thread, much like its Java counterpart. It is quite straightforward though, to add a new thread object to the class, and have that thread perform alternate tasks on alternate data, increasing the class’ complexity. A C++ class that encourages the “one thread per class” rule can be declared as: We can rewrite PrimeThread as: Since PrimeThread inherits from Thread, calling start() on an instance of PrimeThread is all that’s needed. If we insist that all threads must inherit from the Thread class, we’re naturally prevented from more than one thread per class. When used with a callable object, Boost’s thread class imposes a similar constraint. However we’re left with managing two objects.