June 16, 2011, 4:33 p.m.
posted by thorn
In general, when an activity executes, it quickly performs some work and then either reports its completion or (having established one or more bookmarks) yields and waits for stimulus. This pattern maps nicely to a conceptual model in which work items are queued and then dispatched, one at a time, each to a target activity.
This pattern, depicted in Figure, is generally known as scheduling, so the component of the WF runtime that encompasses this functionality is known as the scheduler. The scheduler dispatches work items one at a time (from a queue), in a first-in-first-out (FIFO) fashion. Additionally, because the WF runtime never intervenes in the processing of a work item that has been dispatched, the scheduler behavior is strictly nonpreemptive.
1. WF scheduler
To distinguish the scheduler's internal queue of work items from WF program queues (which are explicitly created by activity execution logic), we will call the queue that holds scheduler work items the scheduler work queue. When its scheduler work queue is empty, a WF program instance is considered idle.
Scheduler Work Items
The work items in the scheduler work queue are delegates. Each work item (delegate) corresponds to a method on an activity in the WF program instance. The activity method that is indicated by a work item (delegate) in the scheduler work queue is known as the execution handler of that work item.
Although there is no API to directly manipulate (or view) the scheduler work queue, certain actions taken by activities will cause work items to be enqueued. Delivery of input to a WF program queue can also cause work items to be enqueued.
A given activity's execution may include the invocation of any number of execution handlers. The state on which execution handlers operate is preserved across invocations of execution handlers of the same activity. This state is heap-allocated and is managed independently of the stack that is associated with the currently running CLR thread. The execution of activities across resumption points is stackless.
Scheduling of work items (delegates) is the mechanism by which methods on activities are invoked. This simple machinery drives activity, and WF program, execution. But in order to understand the rules about how and when work items are enqueued, we must understand the lifecycle of an activity, and that is our next topic.