So I thought I would do option (2) as option (1) is too easy in the XMOS architecture and its not very efficient if I want to run 1MIPs processes on a thread that has 50MIPs available. The code for this is freely available from the virtual threads sourceforge page.

More information after the break…

The base of the system is simple context switching within a single thread – this allows multiple processes to be run on a single thread. The current implementation has only time-slicing for processes and doesn’t currently have any way to handle events, ports or channels in a sensible way. Hopefully this soft of thing will be implemented when I spend some more time on the project.

The tricky things to handle are those which I haven’t implemented yet… The risk of deadlocking the whole lot of virtual threads is quite high when working with events or waiting for external stimulus. Essentially a carefully implemented library would have to be used to stop this, but still provide the level of functionality you get using the hardware threads.

Its probably fairly safe to assert that the virtual threads will not ever be able to be as functional as the hardware threads.

So, a summary of current features:

• Able to start an arbitrary number of virtual threads
• Simple time sliced context switching of virtual threads
• Ability to disable the interrupt for atomic operation

Future features:

• Context switch on external stimulus
• Context switch on demand (so a virtual thread can “release” itself from the current hardware thread)
• Implementation of access to events, channel comms, hardware
• Call to allocate stack space to vthread
• More flexible vthread params (ports, chans, etc)