Programming WCF Services

Resource Synchronization Context

Incoming service calls execute on worker threads. These threads are managed by WCF and are unrelated to any service or resource threads. This means that by default the service cannot rely on any kind of thread affinity, which is always being accessed by the same thread. Much the same way, the service cannot rely by default on executing on some host-side custom threads created by the host or service developers. The problem with this situation is that some resources may rely on thread affinity, for example user-interfaces resources updated by the service must execute and be accessed only by the user-interface (UI) thread. Another example is a resource (or a service) that makes use of the thread local storage (TLS) to store out-of-band information shared globally by all parties on the same thread. Using the TLS mandates use of the same thread. In addition, for scalability and throughput purposes, some resources or frameworks may require being access by their own pool of threads.

Whenever an affinity to a particular thread or threads is expected, the service cannot simply execute the call on the incoming WCF worker thread. Instead, the service must marshal the call to the correct thread(s) required by the resource it accesses.

.NET 2.0 Synchronization Contexts

.NET 2.0 introduced the concept of a synchronization context. The idea is that any party can provide an execution context and have other parties marshal the calls to that context. The synchronization ...