Free-ebooks-library - Bahar Ali Khan

}
}
catch (Exception ex)
{
workItem.TaskSource.SetException (ex);
}
In EnqueueTask, we enqueue a work item which encapsulates the target delegate and
a task completion source—which lets us later control the task that we return to the
consumer.
In Consume, we first check whether a task has been canceled after dequeuing the work
item. If not, we run the delegate and then call SetResult on the task completion
source to indicate its completion.
Here’s how we can use this class:
var pcQ = new PCQueue (1);
Task task = pcQ.EnqueueTask (() => Console.WriteLine ("Easy!"));
...
We can now wait on task, perform continuations on it, have exceptions propagate
to continuations on parent tasks, and so on. In other words, we’ve got the richness
of the task model while, in effect, implementing our own scheduler.
SpinLock and SpinWait
In parallel programming, a brief episode of spinning is often preferable to blocking,
as it avoids the cost of context switching and kernel transitions. SpinLock and Spin
Wait are designed to help in such cases. Their main use is in writing custom synchronization
constructs.
SpinLock
SpinLock and SpinWait are structs and not classes! This design
decision was an extreme optimization technique to avoid the
cost of indirection and garbage collection. It means that you
must be careful not to unintentionally copy instances—by passing
them to another method without the ref modifier, for instance,
or declaring them as readonly fields. This is particularly
important in the case of SpinLock.
The SpinLock struct lets you lock without incurring the cost of a context switch, at
the expense of keeping a thread spinning (uselessly busy). This approach is valid in
high-contention scenarios when locking will be very brief (e.g., in writing a threadsafe
linked list from scratch).
920 | Chapter 22: Parallel Programming