tabs ↹ over ␣ ␣ ␣ spaces

Named locks (using Monitor) in .NET: Performance

26 Feb 2018 47 mins .NET, Multithreading/Parallelism/Asynchronous/Concurrency

One thing remaining from last week’s exploration of named locks is performance. My personal preference was and still is ConcurrentDictionary<TKey, TValue>, but what if the string interning is 10 times faster? That would convince me to thing about it for usage.

What to measure?

I can measure how long does it take to get a lock using one or the other method, but that might be misleading. Both methods need to keep collection of “locks” and look up the one requested. This might have a different complexity (the infamous big-O) based on number of items. Similarly, both methods are, given we’re talking about multithreaded usage here, “thread safe”, thus accessing from multiple threads might change (i.e. internal locking or thread/CPU/bucket/… affinity) the outcome. And finally, the first access might be (or not) more costly (because the item is created) compared to subsequent ones.

Although you can throw into the mix more variables, these three – number of locks, number of threads and number of lock accesses – are the ones I’ll use to get the numbers. The last two, and especially the last one, are very synthetic in my test. Because in real code other factors affect the speed (like CPU cache hits or thrashing).

I’m testing with number of locks 1, 20, 100 and 1000. No particular reason, just values that seemed interesting to me. For numbers of threads (using Tasks) I used 1-6 on Intel Core i5-7500 CPU 3.40GHz (4 logical cores and 4 physical cores). You might be wondering why I went to 6 and didn’t stop at 4 (because that’s the number of cores the CPU has). I wanted to also test the behavior when the processor is slightly oversubscribed and probably some thrashing happens. For number of lock accesses I selected 1, 10, 20, 100, 400, 1000 and 65535. The execution environment is .NET Core 2.0.5 (Framework 4.6.26020.03), 64bit RyuJIT.

To make it more digestible I’ll focus on number of locks and include the remaining variables in a single graph. The raw numbers (including allocations) and code are available at the end of this post.

The graphs show comparison where > 0% means ConcurrentDictionary<TKey, TValue> is faster. Also you can zoom in since these are vector graphics.

1 lock

Well, with one lock it’s questionable whether you need named locks, but let’s take it as an edge case and starting point.

For one lock the string interning is winner for small number of accesses, although it’s starting to lose its edge once number of accesses starts growing. The numbers for number of tasks are not smooth, yet one can see small trend across.

20 locks

This number of locks (together with 100) I consider as something most developers would need. Not a huge number where I would start thinking about different solution (and maybe even distributed locks).

The graph has similar shape as the previous one, but smoother (also the range is different). Somewhere around 20 accesses the ConcurrentDictionary<TKey, TValue> starts to clearly win. I hope for 100 locks the results will be similar, because that would validate my ConcurrentDictionary<TKey, TValue> preference. 😃

100 locks

As I said in paragraph for 20 locks, this number of locks feels like a good fit for the solution we’re talking here about.

For one access the drop continues, but again around 20 accesses the ConcurrentDictionary<TKey, TValue> starts to win. And the trend continues. I like that. 😃

1000 locks

Mostly to see whether there will be some drop, I tested also 1000 locks.

Luckily, the results are not surprising and follow the trend started in previous instances.

Summary

I prefer clean code over some smart (ab)use and ConcurrentDictionary<TKey, TValue> fits into this box perfectly. Usually this is tied to some small (performance) tradeoffs (Ever seen heavily optimized code?). However, I’m happy to see in this case clean code and performance go hand in hand.

As a bonus ConcurrentDictionary<TKey, TValue> gives you more options – different lock types, different keys, … Looks like sometimes we can have nice things.

Implementation

Appendix

Raw numbers

Code

public class TestBench
{
	[Params(1, 2, 3, 4, 5, 6)]
	public int Tasks { get; set; }

	[Params(1, 20, 100, 1000)]
	public int Locks { get; set; }

	[Params(1, 10, 20, 100, 400, 1000, ushort.MaxValue)]
	public int Loops { get; set; }

	[Benchmark(Baseline = true)]
	public void TestDictionaryLock()
	{
		var tester = new DictionaryLock();
		var tasks = new Task[Tasks];
		for (var i = 0; i < Tasks; i++)
		{
			tasks[i] = Task.Run(() => TestImpl(tester));
		}
		Task.WaitAll(tasks);
	}

	[Benchmark]
	public void TestInternLock()
	{
		var tester = new InternLock();
		var tasks = new Task[Tasks];
		for (var i = 0; i < Tasks; i++)
		{
			tasks[i] = Task.Run(() => TestImpl(tester));
		}
		Task.WaitAll(tasks);
	}

	void TestImpl(ILockTester tester)
	{
		var cnt = 0;
		for (var loop = 0; loop < Loops; loop++)
		{
			for (var @lock = 0; @lock < Locks; @lock++)
			{
				cnt += tester.DoSomething(@lock.ToString());
			}
		}
	}
}

interface ILockTester
{
	int DoSomething(string name);
}

class DictionaryLock : ILockTester
{
	ConcurrentDictionary<string, object> _locks;

	public DictionaryLock()
	{
		_locks = new ConcurrentDictionary<string, object>();
	}

	public int DoSomething(string name)
	{
		var locker = _locks.GetOrAdd(name, _ => new object());
		lock (locker)
		{
			return 1;
		}
	}
}

class InternLock : ILockTester
{
	public int DoSomething(string name)
	{
		var locker = string.Intern(name);
		lock (locker)
		{
			return 1;
		}
	}
}

Jiří Činčura is .NET, C# and Firebird expert. He focuses on data and business layers, language constructs, parallelism, databases and performance. For almost two decades he contributes to open-source, i.e. FirebirdClient. He works as a senior software engineer for Microsoft. Frequent speaker and blogger at www.tabsoverspaces.com.