I went to the Hands On Lab Day put on by Victoria .Net today, so thanks go to all the guys and especially Readify’s Mahesh Krishnan for organising the day. I’m a hands-on kind of person, so I learnt heaps of stuff.
I was having a play with the Windows Workflow, building a state machine, and we got on to Parallel processes. Basically, we were trying to determine if a different branch in a Parallel process ran on it’s on thread. The implication was that if it did, then it would work well on multi-processor boxes.
Working with Damian Edwards (also of Readify) we did a few tests. Damo wrote some debugging code inside a Code Activity so that we could see what thread that the process was running on and whether the thread was from the thread pool.
So the answer to the question of whether the different branches can run on different processors is no. Both branches ran on the same thread. This means that a Parallel task only guarantees that it will not continue until all tasks in the various branches are completed.
Then we extended the test program to determine whether different instances of a Workflow run on separate threads.
Our first test appeared to show that instances all ran on the same thread. But the reason that the same thread was used for both instances in the first case was that Windows Workflow utilises the Thread Pool. When the first instance exited, the Workflow engine (which, incidently, also runs in its own thread, and that makes sense) requests the next available thread. In this case, it was the same thread that the first instance had exitted from, and that was because the workflow example we’d created ran too quickly.
So after adding a delay inside the workflow and trying it again, we found that each workflow instance does indeed potentially run on its own thread. Which to me means that Windows Workflow can scale across multiple processors.