Hi Wilfried,
In the Dawn of Time, Salford FTN77 supported multithreading. Later, following sale of soul to devil (which happened in 2 stages, and which is what I call the move to Windows!), multithreading is not officially supported with Clearwin. Whether or not it is with .NET, I can't tell you.
The principles involved in running your Clearwin application on a multiprocessor machine is that up to a point, Windows does appear to use all the cores, but in a way that gives you no real nett benefit - although you can run multiple applications to raise the load on each cpu core.
Each window is a sort of independent application - again, up to a point. I could find no way of making particular windows attach to particular cpu cores, or even to different ones, although some sort of allocation and scheduling must be done by windows.
What I was able to do was to create separate standalone applications that could talk to each other. Then, I found that I could associate particular applications with a given cpu core (through task manager). I imagine that one could also create a flurry of mini-applications that would cause Windows to associate some with one core, and others with another core. Indeed, you can obtain (buy!) software that makes the association of a program with a particular core 'persistent' (I wrote a post in reply to a 'core duo' discussion thread on this).
In your example, you wouldn't get any benefit, because you wouldn't 'switch_to_processor@(2)' until processor 1 had completed the tasks set in 'tell_him_what_to_do@' - whereas if you start_pprocess@, you do move to the next statement (you don't with 'start_process@'). In order to do what you want within a single application, there needs to be specific facilities for multi-threading, and they don't exist. However, a set of intercommunicating applications are, by definition, multithreaded, and Clearwin does have that.
In a multithreaded system, you have to be able to handle the results coming back in an order that is different from the tasks being issued. The phrase that springs to mind is 'client-server computing'. As that is american, the 'client' is a customer in a restaurant, the 'server' is a waiter. If the client has only one server, then the dishes ordered are likely to be served in the correct order. However, if there are several servers, and one is sent for starter, one for main course, and one for wine etc, then the dishes could be delivered in any sequence!
This analogy is nested, for example, the server is effectively the client for the chefs in the kitchen.
With conventional Fortran, there is only one server, and you don't ask him for the main course until after the starter has been delivered!
I think you need a different mindset to cope with multithreading, whichever way you do it.
Eddie
