Well - quite a bit actually.
Firstly, normal generic code is only useful for solving peripheral problems that exist at the end of the processing stack. String handling and date handling are the two classic libraries that come to mind. They can only be used at the end of the stack because it is impossible to know what routines to call next. Our generic threads have (at least) two ends which enables them to be glued together in a long sequence. The threads have no knowledge of processing order. Hence, generic code can be used through the entire width and depth of the application. The implications to cost here are significant.
Secondly, All of the 'processing order' is held within the multithreader hub. The hub acts as system configuration instructing the sequence of the processing through a giant patch panel. Making small changes in the hub can make big changes to how the threads interact.
Thirdly, normal generic code is completely helpless to control an asynchronous event. An event that will complete at some unspecified time in the future and the code can not continue until this event has successfully completed. Our generic code was designed from fundementals to do precisely this.
Other frequently asked questions
Back to our main page