Achieving Named Lock / Locker functionality in C# 4.0

I was recently writing some code to implement a file system cache for streams and came across an interesting dilemma: how do I lock around a file that is being created by ThreadA until it is ready to be accessed by ThreadB? This is not a classic producer/consumer problem as you might be thinking: Any number of threads within a single app domain could be producing or consuming different parts of the cache (files) simultaneously.

The .NET framework doesn’t appear to provide a way to block multiple threads from accessing the same file short of locking the file it’s self and dealing with exceptions that may occur. I prefer to avoid causing un-necessary exceptions and perhaps have a little fun at the same time so I looked for another solution and actually came up with many…

Full blown lock on the entire resource

Everyone has probably seen the below code more times than they’d like. Lock around an object representing a resource until it’s free and other threads are able to access it. The advantage to this code is that is very straight forward and easy to understand. The problem is that the lock is on the entire resource. This means that anyone wanting to interact with the cache, in my example all files in the cache, are blocked until the entire resource frees up.

• Pros
  • Easy to understand
• Cons
  • Slow: Locking on entire resource causes a lot of un-necessary thread blocking on the resource
• Performance
  • 5.8x slower than fastest solution per the demo project

Usage

static object _resourceLocker = new object();
void Write(string key, Stream s)
{
	lock (_resourceLocker )
	{
		//write file
	}
}

Stream Read(string key)
{
	lock (_resourceLocker )
	{
		//read file
	}
}

Named Locking?

From the above example and performance considerations it’s quite apparent that there must be a better solution. In the file system cache example we don’t care if another file in the resource is being accessed, there is no problem with multiple threads working in the cache at the same time, just on the same file. What we need is the ability to lock a single file within the larger cache resource.

Named Mutex Lock

A mutex is similar to the above C# lock with two important distinctions for this use case:

• A mutex is named by a string. This means for this example I could actually lock on the individual file rather than the resource as a whole by keying on the file path.
• A mutex is broadcast to the entire operating system so it is suitable for both itra and inter-process communication. If I was running multiple app domains on this cache this would be a very viable solution as long as each process referenced the same key string in the same way.

The major problem with a mutex however is it’s speed: Since it broadcasts to the entire operating system it is much slower than something that can exist entirely in .NET. In fact the Named Mutex was the slowest of all solutions to this problem clocking in at 5.9 times slower than the fastest solution. Lets also admit it looks pretty ugly too!

• Pros
  • Suitable for interprocess communication (ex: across app domains)
  • Provides named locker functionality
• Cons
  • Slow: OS level broadcast is much slower than staying in the App Domain
  • Overly verbose and possibly confusing code
• Performance
  • 5.9x slower than fastest solution per the demo project

Usage

void Write(string key, Stream s)
{
	using (var mutex = new Mutex(false, key))
	{
		mutex.WaitOne();

		//write file

		mutex.ReleaseMutex();
	}
}

Stream Read(string key)
{
	using (var mutex = new Mutex(false, key))
	{
		mutex.WaitOne();

		//read file

		mutex.ReleaseMutex();
	}
}

Locking on an Interned String

String interning is essentially a way for the .NET CLR to save memory when it comes to string use. As the application is JITing the .NET CLR saves each identical string into a hash table. At run time these ‘different’ strings actually point to the same reference in the hash table so are .Equal() by pointing to the exact same reference in memory.

What makes string interning interesting for the purposes of named locking is that any developer can add to the contents of this cache by using String.Intern() method which both takes and returns the same string. This means that any other time that exact same string is accessed via String.Intern() the same reference in memory will be used which makes it a suitable object to lock on.

Before you get too excited there are a few possible issues with this approach:

If any other code decides to lock on the same string you will likely cause a deadlock at some point in your application because an unexpected lock could be held infinitely blocking one or more threads from running.

The other issue is that the underlying implementation of String.Intern() is very much outside of your control. Furthermore it isn’t really designed for the purposes of locking. Who’s to say that at some future date the CLR might be designed as such to clean up strings from the intern pool to save memory? In fact I couldn’t really find much documentation to guarantee that there is no possible way that a string could leave the intern pool. If this were to happen somehow it’s possible that a lock could be violated compromising the thread safety of our application.

• Pros
  • Provides named locker functionality and is very fast
  • Simple code and relatively easy to understand
• Cons
  • Can cause deadlocks if any other code happens to lock on the same string instance
  • Relies on an implementation that is outside of developer control (CLR) and who’s features could possibly change at any time
• Performance
  • Only 2% slower than fastest solution per the demo project

Usage

void Write(string key, Stream s)
{
	lock (string.Intern(key))
	{
		//write file
	}
}

Stream Read(string key)
{
	lock (string.Intern(key))
	{
		//read file
	}
}

The NamedLocker class

What if we could have something pretty similar to String.Intern() in performance and readability but with none of the cons? This is what caused me to arrive at the NamedLocker class: and it’s only 30 lines of code at most. As you can see below the core of the NamedLocker class relies on a ConcurrentDictionary (.NET 4.0+ is required). Now it’s certainly feasible to roll your own, Microsoft has kindly provided us with a better tested (I hope) and better performing reader writer locked dictionary than I could readily muster.

With the NamedLocker class you have explicit control over the scope of the internal locks and the implementation (the parts that matter) are within your explicit control unlike using String.Intern(). I have also added some code to make quick locks a breeze using lambda expressions to specify the scope of the locks.

The only issue with the NamedLocker class is that reading and writing are dealt with in the same way. In the file system cache example I have no problem with multiple readers, I only want to block readers when there is a writer or block the possiblity of multiple concurrent writers. Not having adistinction between readers and writers should be expected to have a slight performance hit for this situation.

• Pros
  • Provides named locker functionality and is very fast
  • Simple code and easy to understand
• Cons
  • Handles readers and writers under the same lock which is a little less than ideal for performance
• Performance
  • Only .8% slower than fastest solution per the demo project

Usage

static readonly NamedLocker _namedlocker = new NamedLocker();
void Write(string key, Stream s)
{
	lock (_namedlocker.GetLock(key))
	{
		//write file
	}

	//OR

	_namedlocker.RunWithLock(key, () => /*write file*/);
}

Stream Read(string key)
{
	lock (_namedlocker.GetLock(key))
	{
		//read file
	}

	//OR

	return _namedlocker.RunWithLock(key, () => /*read file*/);
}

NamedLocker Implementation

public class NamedLocker
{
	private readonly ConcurrentDictionary<string, object> _lockDict = new ConcurrentDictionary<string, object>();

	//get a lock for use with a lock(){} block
	public object GetLock(string name)
	{
		return _lockDict.GetOrAdd(name, s => new object());
	}

	//run a short lock inline using a lambda
	public TResult RunWithLock<TResult>(string name, Func<TResult> body)
	{
		lock (_lockDict.GetOrAdd(name, s => new object()))
			return body();
	}

	//run a short lock inline using a lambda
	public void RunWithLock(string name, Action body)
	{
		lock (_lockDict.GetOrAdd(name, s => new object()))
			body();
	}

	//remove an old lock object that is no longer needed
	public void RemoveLock(string name)
	{
		object o;
		_lockDict.TryRemove(name, out o);
	}
}

The NamedReaderWriterLocker class

Well here you have it: the best performing class I could muster for a situation where readers and writers should be treated differently. It does everything that NamedLocker does but provides different channels of access for readers than writers allowing for very slightly better performance. The downsides are it can be uglier to use and has a bigger memory footprint than any of the other methods. I have also provided some lambda access patterns that abstract away most of the ugliness of using a ReaderWriterLock. Worth it?

• Pros
  • Provides named locker functionality and is the fastest solution
  • Provides different channels of access for readers and writers reducing contention
• Cons
  • The code required to implement a ReaderWriterLock is uglier and more error prone than most of the other options
• Performance
  • The fastest solution benchmarked in the demo project

Usage

static readonly NamedReaderWriterLocker _namedRwlocker = new NamedReaderWriterLocker();
void Write(string key, Stream s)
{
	var rwLock = _namedRwlocker.GetLock(key);
	try
	{
		rwLock.EnterWriteLock();
		//write file
	}
	finally
	{
		rwLock.ExitWriteLock();
	}

	//OR

	_namedRwlocker.RunWithWriteLock(key, () => /*write file*/);
}

Stream Read(string key)
{
	var rwLock = _namedRwlocker.GetLock(key);
	try
	{
		rwLock.EnterReadLock();
		//read file
	}
	finally
	{
		rwLock.ExitReadLock();
	}

	//OR

	return _namedRwlocker.RunWithReadLock(key, () => /*read file*/);
}

NamedLocker Implementation

public class NamedReaderWriterLocker
{
	private readonly ConcurrentDictionary<string, ReaderWriterLockSlim> _lockDict = new ConcurrentDictionary<string, ReaderWriterLockSlim>();

	public ReaderWriterLockSlim GetLock(string name)
	{
		return _lockDict.GetOrAdd(name, s => new ReaderWriterLockSlim());
	}

	public TResult RunWithReadLock<TResult>(string name, Func<TResult> body)
	{
		var rwLock = GetLock(name);
		try
		{
			rwLock.EnterReadLock();
			return body();
		}
		finally
		{
			rwLock.ExitReadLock();
		}
	}

	public void RunWithReadLock(string name, Action body)
	{
		var rwLock = GetLock(name);
		try
		{
			rwLock.EnterReadLock();
			body();
		}
		finally
		{
			rwLock.ExitReadLock();
		}
	}

	public TResult RunWithWriteLock<TResult>(string name, Func<TResult> body)
	{
		var rwLock = GetLock(name);
		try
		{
			rwLock.EnterWriteLock();
			return body();
		}
		finally
		{
			rwLock.ExitWriteLock();
		}
	}

	public void RunWithWriteLock(string name, Action body)
	{
		var rwLock = GetLock(name);
		try
		{
			rwLock.EnterWriteLock();
			body();
		}
		finally
		{
			rwLock.ExitWriteLock();
		}
	}

	public void RemoveLock(string name)
	{
		ReaderWriterLockSlim o;
		_lockDict.TryRemove(name, out o);
	}
}

Results and Demo Project

Feel free to download the demo project used to generate these results. Each result was calculated from an average of 5 runs on each lock method from a cold start using the constraints in the test project. Hopefully this helped and let us all know if you have found a better way in the comments below!