Our biggest multi-threader so far

It would be very tempting to add threads into our application just for the sake of increasing our maximum thread count, but we don't. All our threads are included for good reasons and gradually, week by week, more threads are designed, coded and added to our application for testing.

However, we have put all our threads into one compiled object which is used to run all our different processes. This is easy to do because different threads can be activated at startup time depending on which type of process is to run.

Using one object gives us the following benefits -

• Only one object is compiled so a faster turn around between development and testing is acheived.
• If there is a problem with processes that contain a large number of threads we will discover it more quickly.
• The kernel context switch between different processes is quicker because they share the same object.
• More pressure is placed on the basic design of the multi-threader to support multiple processes with one object.