Support for multithreading workflows?
Hi,
the announcement of WWF and the beta are great news
. There are nice ways to run and sync workflow services in parallel. But I would like to know in what way the WWF framework supports parallel workflows in one service, i.e. in different threads:
Do I need different workflows in seperated threads and write my own sync mechanisms or can I - in some way I could not figure out - use the designer to split one workflow into different threads?
How can I have two related state machines running in parallel in the same service?
Thanks,
Torsten Pietrek
http:\\topiks.de
How about parallel activity along with calling other workflow in each flow?
(1) Each workflow instance runs in a single CPU thread. This means that .NET code running in the workflow is not required to be slowed by thread synchronisation. Also (2) long running work should be communicated to the host program for execution. The host program runs on a separate thread to the workflow and can create additional worker threads if required for CPU intensive work.
From these two rules you can conclude that due to the first rule activities in a parallel do not actually run simultaneously, and due to the second rule this doesn't impact your ability to have multiple work items execute at the same time.
To try out this pattern for long running work investigate the InvokeMethod and EventSink activities.
Thanks, that is what I needed to know. I will try out the recommended pattern.
Paul , could you elaborate please ?
We've been discussing your answer at work and done some (simple) testing.
First thing we tried is a simple sequential workflow with 3 branches and code activities ( writing some thread & activity info to the console) .
| Branch1 | Branch2 | Branch3 |
| Code 1.1 | Code 2.1 | Code 3.1 |
| Code 1.2 | Code 2.2 | Code 3.2 |
The runtime execution seems to always be:
Code 1.1, Code 2.1, Code 3.1, Code 1.2, Code 2.2, Code 3.2
The code activities in the branches seems to litteraly run from left to right and from top to bottom.
Is this really the order of execution for activies in parallel branches ? If not how is it scheduled ?
When then added some Wait activities:
| Branch1 | Branch2 | Branch3 |
| Wait (20 sec) | Wait (10) Sec | Wait (20sec) |
| Code 1 | Code 2 | Code 3 |
The runtime flow execute
Code2 , Code1, Code3
How does the runtime knows how to perform code 2 before Code1 and Code3 ?
Next test was adding some long loop inside the code activities (not the best way to simulate a code path that takes some time running I know)
| Branch1 | Branch2 | Branch3 |
| Code 1.1 | Code 2.1
(really long time to execute) | Code 3.1 |
| Code 1.2 | Code 2.2 | Code 3.2 |
The runtime execution was:
Code 1.1, Code2.1 , (after a really long time) Code 3.1, Code 1.2, .... as in our first test.
This seems to confirm what we found in our first test & the fact that we need to call the InvokeMehtod activity for long running code.
The Question is then the following:
How come that in sample 2 the execution flow was Code2 , Code1, Code3 ?
Does this impact the way we should design custom activities ?
Lets say I design a custom activty that might take a few second to perform. If I use this activity inside a parallel branch will the execution of this activity block the rest of the branches ?
Altough strange at first glance, I now do see a least 3 benefits of having each workflow instance (even for parallel branches) run in one (cpu) thread:
- No thread synchronization.
- No locking needed on any object instances within the workflow instance context
- State persistence is becoming quite more easy to manage.
Thanks.
Yves,
In answer to your question, yes the parallel activity always schedules its children from left to right. In the example 2, if you looked at the Delay activities that were doing the wait, then the order of scheduling and execution would be:
Delay1, Delay2, Delay3
However after 10 seconds, Delay2 would complete and Code2 would be scheduled for execution. Hence you see Code2 as being executed first. After 10 more seconds Delay1 and Delay3 complete and so you see Code1 and Code3, giving the net execution order of the code activities as
Code2, Code1, Code3
For example3, note that the workflow scheduler is a non-preemptive scheduler that runs a workflow only on one thread at a time. Hence, when your Code2.1 activity takes a very long time, no other activity will execute. Thus when the parallel executes the execution order is:
Code 1.1, Code2.1 , (after a really long time) Code 3.1, Code 1.2, ....
Finally, yes this does impact the way you write executors and event handlers in code. You should not block the execution for a very long time because no other activity will execute in the workflow while you block.
The advantages of this are that you do not have to do explicit concurrency control in code beside or in the executors as you point out making life much easier. However, there are times when locking will be needed:
Consider:
Branch1
Code1 -> Writes variable i;
Code2 -> Reads variable i;
Branch2
Code3 -> Writes variable i;
In this example you may want to use locking so that the value written by Code1 is preserved when Code2 executes. Such locking can be achieved using SynchronizationHandles. I can post more about synchronization and how to achieve it if needed.
Akash.
