When a new thread is connected into the multi-threader hub the job is done. Threads are not 'called' as in traditional software, instead they are activated when the shell recognises that there is nothing to block them.
All the threads share a common interface. This enables any thread to connect with any other thread.
The same thread can be declared many times on the hub allowing the clones to operate independently but concurrently. In other words the functionality of the thread is duplicated but the code itself is not.
A very large generic thread library is being collected. As this increases, more generic threads can be included into customer designs thus decreasing the number of special threads that need to be written.
All the thread connections are declared within the multi-threader hub. This means that the entire application design is contained within the hub and is completely isolated from the rest of the code.
The problem of controlling processes (individually and in groups) has already been solved by system control threads. Threads to control dynamic parameters, to implement trace and debug functions have also been completed.
Traditional software complexity rises exponentially against its size. If you double the size of a system you more than double its complexity. This is not so in the case of a multi-threader.
New threads can easily be connected into a design or major changes can be made without compromising other threads or the overall design.
A useful side effect of a multi-threader is that processing is more efficient. The processor is kept as busy as possible servicing all the threads that can run and doesn't return to the kernel at the first blocked request.
All the threads are controlled identically by the multi-threader shell.
This enables the shell to collect and maintain diagnostic data on every thread.
Many pieces of data are available to the shell which are an invaluable aid to the debugging process.
The overall risk in this type of project is considerably lower because a significant percentage has already been developed and tested. The shell was the first part to be written and has barely changed for over ten years. Also, the inherent flexibility in the design process means that when things do go wrong new solutions can be stitched in with the minimum impact on existing threads.