In the last two chapters, we looked at numerous ways of starting work that will run asynchronously. However, in all of the examples, that work has been relatively self-contained. Asynchrony opens up a whole new class of bugs that can infect your code: race conditions, deadlocks, and data corruption to name just three. We will look at how you debug asynchronous code in Chapters 13 and 14, but our starting point has to be how to prevent these issues in the first place. In this chapter, we will examine the need for thread safety and then introduce the primary tools used to achieve it. In Chapter 5, we will take this idea further and look at the constructs introduced in .NET 4.0 that take some of the work off our shoulders.

Asynchrony and Data

Data is where the trouble starts in asynchronous programming. Not all data is troublesome, of course; but data is at the heart of every asynchrony bug. So first you need to understand where the danger lies: what kinds of data will potentially cause us issues?

static void Main(string[] args)
{
    const int iterations = 100000000;
    const int numTasks = 1;
    List<Task> tasks = new List<Task>();
    int value = 0;
 
    for (int nTask = 0; nTask < numTasks; nTask++)
    {
        Task t = Task.Factory.StartNew(() =>
        {
            IncrementValue(ref value, iterations);
        });
 
        tasks.Add(t);
    }
 
    Task.WaitAll(tasks.ToArray());
    Console.WriteLine("Expected value: {0}, Actual value: {1}", numTasks * iterations, value);
}
 
private static void IncrementValue(ref int value, int iterations)
{
    for (int i = 0; i < iterations; i++)
    {
        value++;
    }
}

The Interlocked Class

The Interlocked static class provides methods to turn nonatomic operations into atomic ones. It is fairly restricted in scope in that it generally only works on single pieces of data up to 64 bits in length (rather than more general data structures). However, as we shall see, there are special rules for using Interlocked with 64-bit values on 32-bit systems.

private static void IncrementValue(ref int value, int iterations)
{
    for (int i = 0; i < iterations; i++)
    {
        Interlocked.Increment(ref value);
    }
}

public struct SpinLock
{
    private int locked;
 
    public void Lock()
    {
        while (Interlocked.Exchange(ref locked, 1) != 0) ;
    }
 
    public void Unlock()
    {
        locked = 0;
    }
}

public static T CompareExchange<T>(
                ref T location,
                T value,
                T comparand) where T : class

public class Highlander
{
   private Highlander()
   {
      Console.WriteLine("created");
   }
 
   private static Highlander theInstance;
 
   public static Highlander GetInstance()
   {
       if (theInstance == null)
       {
           Interlocked.CompareExchange(ref theInstance, new Highlander(), null);
       }
 
       return theInstance;
    }
}

Monitor: The Workhorse of .NET Synchronization

Multistage transition means you need a way of protecting access to data that allows you to control access to arbitrary data. The SmallBusiness class in Listing 4-5 is an example of multistage transition. In this code you can see that when a payment comes in we have to change two separate items of data. Interlocked can’t help us here: not only is decimal too large, but Interlocked only protects access to a single piece of data. The danger with the code in Listing 4-5 is that during ReceivePayment, the state of an instance is temporarily in an invalid state where we have increased the cash but not yet decreased the receivables. If another thread were to access the NetWorth property at that point they would see a value that is too high by the value of the amount parameter.

Listing 4-5.  Example of Multistage State Transition

public class SmallBusiness
{
    private decimal cash;
    private decimal receivables;
  
    public SmallBusiness(decimal cash, decimal receivables)
    {
        this.cash = cash;
        this.receivables = receivables;
    }
  
    public void ReceivePayment(decimal amount)
    {
        cash += amount;
        receivables -= amount;
    }
  
    public decimal NetWorth
    {
        get { return cash + receivables; }
    }
}

To fix this, you have to somehow enforce a protocol that ensures that only one thread at a time has access to this composite state of cash and receivables. The CLR has a construct that can be used for just this purpose; it is known as a Sync Block. Sync Blocks are held in the Sync Block Table in the CLR internal data structures. Every instance of a reference type has an object header. One of the parts of this header is a reference to an entry in the Sync Block Table, which is empty by default. On demand, it will cause an entry in the Sync Block Table to be allocated. The object header will refer to this newly allocated Sync Block.

The Monitor class has a static method called Enter, which will try to take ownership of a Sync Block on behalf of the currently executing thread, potentially triggering allocation of the Sync Block. As a result, from now on we will use the shorthand term of a thread “owning the monitor” to refer to a thread having ownership of a specific Sync Block. A thread relinquishes ownership of a monitor by calling Monitor.Exit.

If a thread, A, calls Monitor.Enter and another thread, B, already owns the specified monitor, then Monitor.Enter blocks until thread B calls Monitor.Exit. When Monitor.Enter returns, thread A will now have ownership of the monitor (see Figure 4-3).

Monitor can therefore be used to prevent concurrent access to state as long as everyone conforms to the protocol. Listing 4-6 shows how we can apply the use of a Monitor to the SmallBusiness class we saw in Listing 4-5. Notice that both the ReceivePayment and NetWorth members need to use the Monitor to ensure no readers ever see the state midtransition.

Listing 4-6.  Thread-Safe SmallBusiness

public class SmallBusiness
{
    private decimal cash;
    private decimal receivables;
    private readonly object stateGuard = new object();
 
    public SmallBusiness(decimal cash, decimal receivables)
    {
        this.cash = cash;
        this.receivables = receivables;
    }
 
    public void ReceivePayment(decimal amount)
    {
        Monitor.Enter(stateGuard);
        cash += amount;
        receivables -= amount;
        Monitor.Exit(stateGuard);
    }
 
    public decimal NetWorth
    {
        get
        {
            Monitor.Enter(stateGuard);
            decimal netWorth = cash + receivables;
            Monitor.Exit(stateGuard);
            return netWorth;
        }
    }
}

This seems quite straightforward but there is a potential problem: what if the code between the Enter and Exit throws an exception? In that case the owning thread would not call Exit and so would leave the monitor in a locked state forever. You therefore need to ensure that you always release the monitor, and for that you can use a try . . . finally block as the code in Listing 4-7 demonstrates.

Listing 4-7.  Releasing the Monitor Using a Finally Block

public void ReceivePayment(decimal amount)
{
    Monitor.Enter(stateGuard);
    try
    {
        cash += amount;
        receivables -= amount;
    }
    finally
    {
        Monitor.Exit(stateGuard);
    }
}

Now, what if Monitor.Enter were to throw an exception? You really need to bring this call inside the try block. But then you need to cater for two possibilities: the exception happening before the monitor was acquired and the exception being thrown after the monitor was acquired. So you need to have some way of telling whether or not you should release the monitor. Fortunately, in version 4.0 of .NET a new overload was introduced that allows users to verify, one way or the other, whether the lock was taken. Listing 4-8 shows the code necessary to use this new overload.

Listing 4-8.  Monitor.Enter Inside the try Block

public void ReceivePayment(decimal amount)
{
    bool lockTaken = false;
    try
    {
        Monitor.Enter(stateGuard, ref lockTaken);
        cash += amount;
        receivables -= amount;
    }
    finally
    {
        if (lockTaken)
        {
            Monitor.Exit(stateGuard);
        }
    }
}

If this is the code you should write to use monitors correctly, you have a problem: the chances of getting developers to write this every time and get it right every time are not great. And so the C# language has a keyword that makes the compiler emit the code in Listing 4-8.

public void ReceivePayment(decimal amount)
{
    lock(stateGuard)
    {
        cash += amount;
        receivables -= amount;
    }
}

public void ReceivePayment(decimal amount)
{
    bool lockTaken = false;
  
    try
    {
        Monitor.TryEnter(stateGuard, TimeSpan.FromSeconds(30), ref lockTaken);
        if (lockTaken)
        {
            cash += amount;
            receivables -= amount;
        }
        else
        {
            throw new TimeoutException("Failed to acquire stateGuard");
        }
    }
    finally
    {
        if (lockTaken)
        {
            Monitor.Exit(stateGuard);
        }
    }
}

public static class LockExtensions
{
    public static LockHelperLock(this object obj, TimeSpan timeout)
    {
        bool lockTaken = false;
  
        try
        {
            Monitor.TryEnter(obj, TimeSpan.FromSeconds(30), ref lockTaken);
            if (lockTaken)
            {
                return new LockHelper(obj);
            }
            else
            {
                throw new TimeoutException("Failed to acquire stateGuard");
            }
        }
        catch
        {
            if (lockTaken)
            {
                Monitor.Exit(obj);
            }
            throw;
        }
    }
  
    private struct LockHelper : IDisposable
    {
        private readonly object obj;
  
        public LockHelper(object obj)
        {
            this.obj = obj;
        }
  
        public void Dispose()
        {
            Monitor.Exit(obj);
        }
    }
}

public void ReceivePayment(decimal amount)
{
    using(stateGuard.Lock(TimeSpan.FromSeconds(30)))
    {
        cash += amount;
        receivables -= amount;
    }
}

private static void Produce(object obj)
{
    var queue = (Queue<int>)obj;
    var rnd = new Random();
  
    while (true)
    {
        lock (queue)
        {
            queue.Enqueue(rnd.Next(100));
  
            Monitor.Pulse(queue);
        }
  
        Thread.Sleep(rnd.Next(2000));
     }
}
  
private static void Consume(object obj)
{
    var queue = (Queue<int>)obj;
  
    while (true)
    {
        int val;
        lock (queue)
        {
            while (queue.Count == 0)
            {
                Monitor.Wait(queue);
            }
  
            val = queue.Dequeue();
        }
  
        ProcessValue(val);
    }
}

public class MonitorSemaphore
{
    private int currentCount;
    private readonly int maxCount;
    private readonly object guard = new object();
  
    public MonitorSemaphore(int initialCount, int maxCount)
    {
        this.currentCount = initialCount;
        this.maxCount = maxCount;
    }
  
    public void Enter()
    {
        lock (guard)
        {
            while (currentCount == maxCount)
            {
                Monitor.Wait(guard);
            }
            currentCount++;
        }
    }
  
    public void Exit()
    {
        lock (guard)
        {
            currentCount--;
            Monitor.Pulse(guard);
        }
    }
  
    public int CurrentCount{get { return currentCount; }}
}

Optimizing for Read

So far we have been focusing on achieving thread safety via mutual exclusion: only one thread accessing thread sensitive code at a time. In situations of low contention, where it is unusual for two threads to want to access state at the same time, this is often the optimal approach, as you just use a lightweight guard to ensure those rare occasions are safe.

Sometimes, however, you will find yourself in a very different usage pattern, where many threads want to read a piece of state concurrently and occasionally a thread will need to perform an update. Because of this update you need to ensure thread safety via synchronization, but if you use mutual exclusion only one reader will be able to access the state at a time. We know that if every thread were reading, there would be no thread safety concerns, so the ideal situation would be if you could let lots of readers in at the same time, but then shut them out to allow a single writer access to the state. This is the role of a reader/writer lock.

There are two reader/writer locks in the .NET framework: ReaderWriterLock and ReaderWriterLockSlim. Why are there two? Well, let’s look at their behavior.

var rwLock = new ReaderWriterLock();
  
rwLock.AcquireReaderLock(TimeSpan.FromSeconds(3));
try
{
    ReadState();
}
finally
{
    rwLock.ReleaseReaderLock();
}

var rwLock = new ReaderWriterLockSlim();
  
rwLock.EnterReadLock();
try
{
    ReadState();
}
finally
{
    rwLock.ExitReadLock();
}

public class Cache
{
    private readonly List<NewsItem> items = new List<NewsItem>();
  
    ReaderWriterLockSlim guard = new ReaderWriterLockSlim();
  
    public IEnumerable<NewsItem> GetNews(string tag)
    {
        guard.EnterReadLock();
        try
        {
            return items.Where(ni => ni.Tags.Contains(tag)).ToList();
        }
        finally
        {
            guard.ExitReadLock();
        }
    }
  
    public void AddNewsItem(NewsItem item)
    {
        guard.EnterWriteLock();
        try
        {
           items.Add(item);
        }
        finally
        {
            guard.ExitWriteLock();
        }
    }
}

A Semaphore Out of the Box

Earlier in this chapter you implemented a semaphore using the Wait and Pulse methods of the Monitor class. In .NET 4.0 the .NET framework team shipped a managed semaphore as part of the System.Threading namespace. There was already a Semaphore class (we’ll come to this in a little while), so the new class was called SemaphoreSlim (you might be able to see a pattern emerging here). Internally, SemaphoreSlim uses the Wait and Pulse methods of the Monitor class, in a similar way to our version, so it is a very lightweight synchronization primitive. As explained earlier, semaphores are typically used to guard access to a limited resource such as a thread pool. Let’s look at an example by implementing a Large Object Heap buffer pool.

To start with, we’ll model the buffer by a pair of abstractions: one to model the actual buffer and the other to help us with resource management. You can see these in Listing 4-18. IBufferRegistration allows the user of the buffer to say they are finished with it, so it can be returned to the pool.

Listing 4-18.  Abstractions for the Buffer Pool

public interface IBuffer
{
    byte[] Buffer { get; }
}
public interface  IBufferRegistration : IBuffer, IDisposable
{
}

Next you need an implementation of a buffer that will reside on the LOH. To ensure this, make sure the buffer is 85,000 bytes (the actual limit is slightly lower, but 85,000 is a nice round number). Listing 4-19 shows the implementation. Note the InUse flag: this allows you to locate pooled buffers that are not currently in use.

Listing 4-19.  Wrapping a LOH Buffer

public class LOHBuffer : IBuffer
{
    private readonly byte[] buffer;
    private const int LOHBufferMin = 85000;
    internal bool InUse { get; set; }
  
    public LOHBuffer()
    {
        buffer = new byte[LOHBufferMin];
    }
  
    public byte[] Buffer { get { return buffer; } }
}

Last, you need the actual pool; this uses a semaphore to ensure that if we are using the maximum number of buffers, then the next attempt to obtain one will block until one becomes free. We wrap the LOHBuffer in a BufferRegistration class that returns the buffer to the pool when disposed. The code for the pool is shown in Listing 4-20, and although the semaphore is only a small part of the code, it is critical to ensure that we constrain the pool and block requestors that exceed the maximum concurrent buffers.

Listing 4-20.  The BufferPool Implementation

public class BufferPool
{
    private SemaphoreSlim guard;
    private List<LOHBuffer> buffers;
  
    public BufferPool(int maxSize)
    {
        guard = new SemaphoreSlim(maxSize);
        buffers = new List<LOHBuffer>(maxSize);
    }
  
    public IBufferRegistration GetBuffer()
    {
        // this blocks until a buffer is free
        guard.Wait();
        // can now get buffer so make sure we're the only thread manipulating
        // the list of buffers
        lock (buffers)
            {
                IBufferRegistration freeBuffer = null;
 
                // look for a free buffer
                foreach (LOHBuffer buffer in buffers)
                {
                    if (!buffer.InUse)
                    {
                        buffer.InUse = true;
                        freeBuffer = new BufferReservation(this, buffer);
                    }
                }
  
                // no free buffer so allocate a new one
                if (freeBuffer == null)
                {
                    var buffer = new LOHBuffer();
                    buffer.InUse = true;
                    buffers.Add(buffer);
                    freeBuffer = new BufferReservation(this, buffer);
                }
  
                return freeBuffer;
            }
        }
  
        private void Release(LOHBuffer buffer)
        {
            // flag buffer as no longer in use and release the semaphore
            // to allow more requests into the pool
            buffer.InUse = false;
            guard.Release();
        }
  
        class BufferReservation : IBufferRegistration
        {
            private readonly BufferPool pool;
            private readonly LOHBuffer buffer;
  
            public BufferReservation(BufferPool pool, LOHBuffer buffer)
            {
                this.pool = pool;
                this.buffer = buffer;
            }
  
            public byte[] Buffer
            {
                get { return buffer.Buffer; }
            }
  
            public void Dispose()
            {
                pool.Release(buffer);
            }
        }
    }

Raising the Starting Gate: ManualResetEventSlim

We saw how the Monitor class can be used to raise notifications with Pulse and PulseAll. These APIs are, however, fairly low level, requiring the thread wanting notification to take special actions. .NET 4.0 introduced the ManualResetEventSlim class that wraps up the low-level API into something easier to use.

A ManualResetEventSlim has two states: Set and Unset. If the event is Set, then a thread calling Wait will return immediately. If the event is Unset, then calling Wait will block until the event transitions to the Set state. The constructor takes the initial state (default to Unset) and the Set and Reset methods change the event’s state to Set and Unset, respectively.

ManualResetEventSlim can be used for general purpose signaling between threads, but is also commonly used to ensure that a group of threads does not proceed beyond a certain point until some initialization work has been completed.

For example, imagine you have a set of threads that load data from various data sources for processing. The exact processing required is based on a configuration file that is generated from another system, so once the threads have loaded the initial data, they cannot proceed until the configuration file is available. A ManualResetEventSlim is the ideal synchronization primitive here, as the processing threads call Wait after the initial data load, which will block. Once the configuration file is available, Set is called, which wakes up the processing threads. They now read the file, obtain the processing parameters they need, and start processing. Listing 4-21 shows the controlling thread that sets the event, and Listing 4-22 shows the processing thread that performs its initial work and then waits for the control file by waiting on the event.

Listing 4-21.  Processing Control Thread

static void Main(string[] args)
{
    var matchers = new[] {"dowjones", "ftse", "nasdaq", "dax"};
    var controlFileAvailable = new ManualResetEventSlim();
    var tasks = new List<Task>();
  
    foreach (string matcherName in matchers)
    {
        var matcher = new Matcher(matcherName, MatchesFound, controlFileAvailable);
        tasks.Add(matcher.Process());
    }
  
    Console.WriteLine("Press enter when control file ready");
    Console.ReadLine();
  
    controlFileAvailable.Set();
  
    Task.WaitAll(tasks.ToArray());
}

Listing 4-22.  Processing Thread

private void InternalProcess()
{
    IEnumerable<TradeDay> days = Initialize();
  
    controlFileAvailable.Wait();
  
    ControlParameters parameters = GetControlParameters();
    IEnumerable<TradeDay> matchingDays = null;
    if (parameters != null)
    {
        matchingDays = from d in days
                       where d.Date >= parameters.FromDate &&
                             d.Date <= parameters.ToDate && d.Volume >= parameters.Volume
                       select d;
    }
 
    matchesFound(dataSource, matchingDays);
}
 

CountdownEvent: Simplifying Fork and Join

You saw in Chapter 3 that parent/child tasks can be used to model the fork-and-join pattern, where the parent splits up a complex task into a set of child tasks that can run concurrently. The parent task is then not deemed complete until all the child tasks have finished. This allows code interested in the completion of the entire process to simply wait for the parent to complete. However, what if it isn’t completion that is of interest, but rather an intermediate state, or whether it’s impractical for a single task to spawn the other tasks? In this case it would be useful to have another primitive that could keep a count of completions.

CountdownEvent was introduced in .NET 4.0 to give a flexible way for a “controller” to synchronize with a set of subordinate tasks. We could achieve a similar effect by associating each subordinate task with a ManualResetEventSlim and then have the controller wait on all of the events, but this becomes ungainly with many subordinate tasks. CountdownEvent provides a single primitive that keeps track of a count internally. When a controller calls Wait it blocks until this internal count reaches zero. The count is decreased by a subordinate task calling Signal on the CountdownEvent.

Returning to the data-matching example from Listings 4-21 and 4-22, if the requirement changes so the controller (Main in Listing 4-21) should not change the control file until all the matchers have finished their initialization, then we can use a CountdownEvent to provide this coordination. Main waits on the CountdownEvent before replacing the control file, and the matchers signal the CountdownEvent when they have finished their initialization. We can see the updated code in Listing 4-23 and 4-24.

Listing 4-23.  Controller Waiting on CountdownEvent

static void Main(string[] args)
{
    var matchers = new[] {"dowjones", "ftse", "nasdaq", "dax"};
    var controlFileAvailable = new ManualResetEventSlim();
    var tasks = new List<Task>();
  
    var initializationComplete = new CountdownEvent(matchers.Length);
  
    foreach (string matcherName in matchers)
    {
        var matcher = new Matcher(matcherName,
                                  MatchesFound,
                                  controlFileAvailable,
                                  initializationComplete);
        tasks.Add(matcher.Process());
    }
  
    initializationComplete.Wait();
  
    Console.WriteLine("Press enter when control file ready");
    Console.ReadLine();
  
    controlFileAvailable.Set();
  
    Task.WaitAll(tasks.ToArray());
}

Listing 4-24.  Worker Signalling CountdownEvent

private void InternalProcess()
{
    IEnumerable<TradeDay> days = Initialize();
  
    initializationComplete.Signal();
  
    controlFileAvailable.Wait();
  
    ControlParameters parameters = GetControlParameters();
    IEnumerable<TradeDay> matchingDays = null;
    if (parameters != null)
    {
        matchingDays = from d in days
                       where d.Date >= parameters.FromDate &&
                             d.Date <= parameters.ToDate &&
                             d.Volume >= parameters.Volume
                       select d;
    }
    matchesFound(dataSource, matchingDays);
}

As with all of the synchronization primitives introduced in .NET 4.0, the Wait method can take a timeout and a CancellationToken. The CountdownEvent’s internal count can be manipulated by the AddCount and TryAddCount method, which increase it, and the Reset method, which returns it to the original, or a specific, value.

Barrier: Rendezvous-Based Synchronization

Both ManualResetEvent and CountdownEvent are used when an external controller or coordinator are involved with asynchronous work. However, for some kinds of work, we need the workers to coordinate their activity between themselves. A common situation where this is necessary is when using geometric decomposition to evaluate the state of a system over a series of time intervals (for example calculating the weather).

The issue is that, because of the edge conditions, each new time interval can only be calculated once all concurrent calculations for the current time interval have completed. The individual tasks, therefore, need a way to ensure that, once they have completed the current time interval, they wait until everyone has gotten to the same stage—essentially arranging a rendezvous point.

Listing 4-25 shows an example of calculating heat diffusion over a series of iterations using geometric decomposition. The Material class models the material over which heat is diffusing, and two Material buffers are alternatively used as the source data and new generated values. The Range class is used to break the material into the chunks on which to apply the diffusion algorithm. Last, the Barrier is used to ensure that each Task has finished its current iteration before any of the Tasks move on to the next iteration.

Listing 4-25.  Geometric Decomposition Controlled with a Barrier

Material DiffuseHeat(Material material, int iterations)
{
    Material[] materials = new Material[2];
    materials[0] = material;
    materials[1] = new Material(materials[0].Width);
    materials[1][0] = material[0];
    materials[1][material.Width - 1] = material[material.Width - 1];
  
    double dx = 1.0 / (double)material.Width;
    double dt = 0.5 * dx * dx;
  
    int nCores = 4;
    Range range = new Range() { Start = 1, End = material.Width - 1 };
  
    Barrier barrier = new Barrier(nCores);
  
    Task[] tasks = new Task[nCores];
    int nTask = 0;
  
    foreach (Range subRange in range.CreateSubRanges(nCores))
    {
        Range localRange = subRange;
        tasks[nTask++] =
        Task.Factory.StartNew(() =>
        {
            for (int nIteration = 0; nIteration < iterations; nIteration++)
            {
                Material src = materials[nIteration%2];
                Material dest = materials[(nIteration + 1)%2];
  
                for (int x = localRange.Start; x <= localRange.End; x++)
                {
                    dest[x] = src[x] + (dt/(dx*dx))*(src[x + 1] - 2*src[x] + src[x - 1]);
                }
  
                barrier.SignalAndWait();
            }
        });
  
   }
   Task.WaitAll(tasks);
             
   return material;
}

The Barrier can also be passed an Action<Barrier> delegate, which gets executed once all of the tasks have arrived at the rendezvous but before they are all released from their wait. This allows the delegate exclusive access to the data so it can retrieve any required interim results. The number of participants in the coordination (passed to the Barrier constructor) can vary over time via the AddParticipant and RemoveParticipant methods on the Barrier class. Last, as usual, the SignalAndWait method can take a timeout and a CancellationToken.

Crossing the AppDomain Boundary with WaitHandle

So far every synchronization construct that we have looked at is implemented fully in managed code. On that basis none of these primitives can be used to coordinate activity between AppDomains and separate processes. Sometimes you will need to be able to control access or signal beyond a single AppDomain. For example, if two applications both needed to update the same file then you would need to control access to the file between the processes. If the code was running in the same AppDomain, you could quite easily use a Monitor, but that isn’t going to work cross-process. Another quite common requirement is to have only one instance of an application running, so that attempting to start another instance in fact just brings the existing instance to the fore. To achieve a single instance, you need some kind of signaling mechanism between the existing instance and the new instance.

The kernel has its own synchronization primitives: Mutex, Semaphore, ManualResetEvent, and AutoResetEvent. As these are kernel mode constructs they can be used for synchronization across the AppDomain and process boundaries. They all have the concept of being in a signaled and nonsignaled state.

public partial class App : Application
{
    private const string eventName = "84bb9974-fb13-4927-bf47-91f9fca1601c";
    private EventWaitHandle singleInstanceEvent;
  
    protected override void OnStartup(StartupEventArgs e)
    {
        bool created;
        singleInstanceEvent = new EventWaitHandle(false,
                                                  EventResetMode.AutoReset,
                                                  eventName,
                                                  out created);
  
        if (!created)
        {
            singleInstanceEvent.Set();
            Shutdown();
        }
        else
        {
            SynchronizationContext ctx = SynchronizationContext.Current;
            Task.Factory.StartNew(() =>
                    {
                        while (true)
                        {
                            singleInstanceEvent.WaitOne();
                            ctx.Post(_ => MakeActiveApplication(), null);
                        }
                    });
        }
  
        base.OnStartup(e);
    }
  
    private void MakeActiveApplication()
    {
        MainWindow.Activate();
        MainWindow.Topmost = true;
        MainWindow.Topmost = false;
        MainWindow.Focus();
    }
}

Synchronization Is Not the Only Answer

Cast your mind back to the start of this chapter. Remember, we only need synchronization when we have shared, mutable data with nonatomic update. Sometimes it is possible to restructure an algorithm to take advantage of this fact rather than having to introduce synchronization primitives.

In Listing 4-17 we reviewed using ReaderWriterLockSlim to optimize a news cache for high read and low write concurrency. This is obviously a huge improvement over using a Monitor that serializes all of the reads, but the reader is still paying a cost both in terms of having to take a read lock and, more importantly, having to create a copy of the matching news items using ToList. In an ideal world you could have the readers all free-running, even if we have to make the write operation much more expensive, as reads are far more frequent than writes.

The CLR gives you a very important guarantee: reference assignment is always atomic. On 32-bit CLR, references are 32 bit, and on 64-bit CLR, they are 64 bit. This means they can be assigned in a single processor instruction. You can therefore rewrite the AddNewsItem method to copy the existing news cache items (this is a read operation on the list), add the new item to the copy, and then assign the copy as the new items list. At this point the GetNews method is no longer affected by the AddNewsItem and so does not need synchronization. If you want to support multiple writers, you will still need synchronization in the AddNewsItem to ensure only one item is added at a time, but you can use a Monitor for this. You can see an implementation in Listing 4-27. Note that GetNews no longer needs to use ToList to copy the matching news items.

Listing 4-27.  Lock-Free Implementation of the News Cache

public class LockFreeCache
{
    private List<NewsItem> items = new List<NewsItem>();
  
    readonly object writeGuard = new object();
  
    public IEnumerable<NewsItem> GetNews(string tag)
    {
        return items.Where(ni => ni.Tags.Contains(tag));
    }
  
    public void AddNewsItem(NewsItem item)
    {
        lock (writeGuard)
        {
            var copy = new List<NewsItem>(items);
            copy.Add(item);
            items = copy;
        }
    }
}

Before you get too excited and go and attempt to change all of your code to lock-free algorithms, some notes of caution.

• Not all algorithms can be written lock free; there are often inherent issues in the functionality that force synchronization.
• Writing lock-free algorithms is very often far more complex than the example in Listing 4-27. There can be many subtle race conditions and they commonly require the use of Interlocked.Exchange and Interlocked.CompareAndExchange.
• Most code won’t benefit from being lock free, as the level of contention is, in reality, very small. Synchronization is needed to ensure correct behavior, but the code very rarely ends up waiting for a lock. In this case there is no real advantage in using a lock-free algorithm.

Conclusion

As soon as you create multithreaded code, you have to take thread safety into consideration. As you have seen, the .NET framework provides many tools, with different costs and approaches, to help you achieve thread safety, but it only provides the tools. It is up to us, as developers, to use the appropriate approach correctly to achieve safety at a minimum cost.

In some ways it would be good if the framework classes themselves were inherently thread safe, but in reality this would add a big overhead for code that often doesn’t need that feature. However, from .NET 4.0 on there has been a set of data structures that are, in fact, designed for concurrency—but that is the subject of the next chapter.