When the service is configured with ConcurrencyMode.Single, WCF will provide automatic synchronization to the service context and disallow concurrent calls by associating the context containing the service instance with a synchronization lock. Every call coming into the service must first try to acquire the lock. If the lock is unowned, the caller will be allowed in. Once the operation returns, WCF will unlock the lock, thus allowing in another caller.

The important thing is that only one caller at a time is ever allowed. If there are multiple concurrent callers while the lock is locked, the callers are all placed in a queue and are served out of the queue in order. If a call times out while blocked, WCF will remove the caller from the queue and the client will get a TimeoutException. The ConcurrencyMode.Single is the WCF default setting, so these definitions are equivalent:

class MyService : IMyContract
{...}

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Single)]
class MyService : IMyContract
{...}

Because the default concurrency mode is synchronized access, the susceptible instancing modes of per-session and singleton are also synchronized by default. Note that even calls to a per-call service instance are synchronized by default.

When the service is configured with ConcurrencyMode.Multiple, WCF will stay out of the way and will not synchronize access to the service instance in any way. ConcurrencyMode.Multiple simply means that the service instance is not associated with any synchronization lock, so concurrent calls are allowed on the service instance. Put differently, when a service instance is configured with ConcurrencyMode.Multiple, WCF will not queue up the client messages and dispatch them to the service instance as soon as they arrive.

Obviously, this is of great concern to sessionful and singleton services, which must manually synchronize access to their instance state. The common way of doing that is to use .NET locks such as Monitor or a WaitHandle-derived class. Manual synchronization, which is covered in great depth in Chapter 8 of my book Programming .NET Components, Second Edition (O’Reilly), is not for the faint of heart, but it does enable the service developer to optimize the throughput of client calls on the service instance: you can lock the service instance just when and where synchronization is required, thus allowing other client calls on the same service instance in between the synchronized sections. Example 8-1 shows a manually synchronized sessionful service whose client performs concurrent calls.

[ServiceContract(SessionMode = SessionMode.Required)]
interface IMyContract
{
   void MyMethod();
}

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]
class MyService : IMyContract
{
   int[] m_Numbers;
   List<string> m_Names;

   public void MyMethod()
   {
      lock(m_Numbers)
      {
         ...
      }

      /* Don't access members here */

      lock(m_Names)
      {
         ...
      }
   }
}

The service in Example 8-1 is configured for concurrent access. Since the critical sections of the operations that require synchronization are any member variable accesses, the service uses a Monitor (encapsulated in the lock statement) to lock the member variable before accessing it. I call this synchronization technique fragmented locking, since it locks only when needed and only what is being accessed. Local variables require no synchronization, because they are visible only to the thread that created them on its own call stack.

There are two problems with fragmented locking: it is both error- and deadlock-prone. Fragmented locking only provides for thread-safe access if every other operation on the service is as disciplined about always locking the members before accessing them. But even if all operations lock all members, you still risk deadlocks: if one operation on thread A locks member M1 while trying to access member M2, while another operation executing concurrently on thread B locks member M2 while trying to access member M1, you will end up with a deadlock.

It is better to reduce the fragmentation by locking the entire service instance instead:

public void MyMethod()
{
   lock(this)
   {
      ...
   }

   /* Don't access members here */

   lock(this)
   {
      ...
   }
}

This approach, however, is still fragmented and thus error-prone—if at some point in the future someone adds a method call in the unsynchronized code section that does access the members, it will not be a synchronized access. It is better still to lock the entire body of the method:

public void MyMethod()
{
   lock(this)
   {
      ...
   }
}

The problem with this approach is that in the future someone maintaining this code may err and place some code before or after the lock statement. Your best option therefore is to instruct the compiler to automate injecting the call to lock the instance using the MethodImpl attribute with the MethodImplOptions.Synchronized flag:

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]
class MyService : IMyContract
{
   int[] m_Numbers;
   List<string> m_Names;

   [MethodImpl(MethodImplOptions.Synchronized)]
   public void MyMethod()
   {
      ...
   }
}

You will need to repeat the assignment of the MethodImpl attribute on all the service operation implementations.

While this code is thread-safe, you actually gain little from the use of ConcurrencyMode.Multiple: the net effect in terms of synchronization is similar to using ConcurrencyMode.Single, yet you have increased the overall code complexity and reliance on developers’ discipline. In general, you should avoid ConcurrencyMode.Multiple. However, there are cases where ConcurrencyMode.Multiple is useful, as you will see later in this chapter.

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]
class MyService : IMyContract
{
   public void MyMethod()
   {...}
   public void MyOtherMethod()
   {...}
}

//Invalid configuration:
[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple)]
class MyService : IMyContract
{
   [OperationBehavior(TransactionScopeRequired = true)]
   public void MyMethod()
   {...}
   public void MyOtherMethod()
   {...}
}

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Multiple,
                 ReleaseServiceInstanceOnTransactionComplete = false)]
class MyService : IMyContract
{
   [OperationBehavior(TransactionScopeRequired = true)]
   public void MyMethod()
   {...}
   public void MyOtherMethod()
   {...}
}

The ConcurrencyMode.Reentrant value is a refinement of ConcurrencyMode.Single. Similar to ConcurrencyMode.Single, ConcurrencyMode.Reentrant associates the service context with a synchronization lock, so concurrent calls on the same instance are never allowed. However, if the reentrant service calls out to another service or a callback, and that call chain (or causality) somehow winds its way back to the service instance, as shown in Figure 8-1, that call is allowed to reenter the service instance.

Figure 8-1. Call reentrancy

The implementation of ConcurrencyMode.Reentrant is very simple—when the reentrant service calls out over WCF, WCF silently releases the synchronization lock associated with the instance context. ConcurrencyMode.Reentrant is designed to avoid the potential deadlock of reentrancy, although it will release the lock in case of a callout. If the service were to maintain the lock while calling out, if the causality tried to enter the same context, a deadlock would occur.

Reentrancy support is instrumental in a number of cases:

interface IMyContractCallback
{
   [OperationContract]
   void OnCallback();
}
[ServiceContract(CallbackContract = typeof(IMyContractCallback))]
interface IMyContract
{
   [OperationContract]
   void MyMethod();
}

[ServiceBehavior(ConcurrencyMode = ConcurrencyMode.Reentrant)]
class MyService : IMyContract
{
   public void MyMethod()
   {
      IMyContractCallback callback = OperationContext.Current.
                                         GetCallbackChannel<IMyContractCallback>();
      callback.OnCallback();
   }
}