A number of customers have asked about the threading model used for WF 4. In brief, our extensibility for threading in the WF Runtime is based on System.Threading.SynchronizationContext.

When a execution is kicked off (indirectly through ActivityRuntime.Run), we will first call SynchronizationContext.OperationStarted(). Next we will call SynchronizationContext.Post() to get on a “workflow” thread.

We will then execute any pending work items from our internal scheduler queue. It is possible that more work items will be scheduled (through context.ResumeBookmark, context.ScheduleActivity or activity completion). In that case, we will continue to execute those work items as well. Execution will remain on the “workflow thread” until we either go idle (no more work items), or the runtime is explicitly paused by the host through ActivityRuntime.RequestPause (which is what’s called underneath Unload() for example). When this happens, we will call SynchronizationContext.OperationCompleted().

How you configure a SynchronizationContext depends on the host construct that you are using.

1. For WorkflowServiceHost, we will use the the value of SynchronizationContext.Current at the time of workflowServiceHost.Open (unless UseSynchronizationContext is set to false). This is consistent with the rest of WCF.
2. WorkflowInvoker.Invoke/BeginInvoke has overloads where you can explicitly provide a SynchronizationContext for us to use
3. WorkflowInvoker.InvokeAsync will use the value of SynchronizationContext.Current for consistency with the Whidbey async pattern
4. WorkflowInstance has a constructor overload which allows you to explicitly provide a SynchronizationContext for us to use

If no SynchronizationContext is provided by the host, we will use an internal WF default SynchronizationContext. The WF default SynchronizationContext uses IO completion ports under the hood to implement Post().

A few customers have hit a speed bump when trying to setup persistence with WF4 Beta1. We have multiple sql scripts included (for 3.5 persistence and 4.0 persistence). The problem is that depending on your WF application model in Beta1 you have to execute different scripts (we’ve fixed this in Beta2).

For WorkflowServiceHost usage, use these SQL scripts:

• C:WindowsMicrosoft.NETFrameworkv4.0.20408SQLenSqlPersistenceProviderSchema40.sql
• C:WindowsMicrosoft.NETFrameworkv4.0.20408SQLenSqlPersistenceProviderLogic40.sql

For WorkflowInstance usage, use these SQL scripts (note the lack of “40”):

• C:WindowsMicrosoft.NETFrameworkv4.0.20408SQLenSqlPersistenceProviderSchema.sql
• C:WindowsMicrosoft.NETFrameworkv4.0.20408SQLenSqlPersistenceProviderLogic.sql

Also make sure that the connection string in your application matches the database you created.

One of the investments we’ve made in WF4 is to increase the number of activities provided by the system. Leon has a nice overview of the activities included in Beta 1 here.

Slides should be available soon on Channel9. Until then, I’ve made them available here.