Threading in C#: Part III

by Emanuel Scirlet | Nov 3, 2015 | .NET, C#

Hello, as promised this is a continuation of Part II of the C# threading series. I hope you your time is well spent here.

Locking
Exclusive locking ensures that only one thread can access a particular section of the code at any given time. The main mechanisms used for exclusive locking are lock and mutex.
For non-exclusive locking semaphores are used. The difference between the two is that while locking is easier and faster, mutex allows to span locking across applications and different processes, for instance a common resource like a file.

[code lang=”csharp”]
class Test{
int x=5;

void Calc(){
x+=5;
Console.WriteLine(x);
}
}
[/code]

This class is not thread-safe and the output is unpredictable. The thread safe code is to be found below and makes use of locks.

[code lang=”csharp”]
class Test{
int x=5;
object _lock = new object();

void Calc(){
lock(_locker){
x+=5;
Console.WriteLine(x);
}
}
}
[/code]

Only one thread can lock the synchronizing object at a time, while any other threads are blocked until the lock is released.
If other threads are trying to lock the object they’re going to be served in a queue but with no guaranteed order. Threads that are waiting for accessing a locked area are in a WaitSleepJoin state.
There is a trick here: if an exception happens in the lock section then that part of the code won’t be released and other threads will be waiting for ever. Aside from that there are more subtle details here on Monitors but won’t get into that now.

Deadlocking is one of the hardest problems in multi-threading, especially when there are many objects that interact with each other. The main problem is that you can’t be sure what locks your caller has taken out.
So, you might lock a private field a within your class X, unaware that your caller (or caller’s caller) has already locked the field b within class Y. Meanwhile, another thread is doing exactly the reverse, creating a deadlock.
Another example of deadlocking arises when calling Dispatcher.Invoke (in WPF) or Control.Invoke (in Windows Forms) while in possession of a lock. If the UI happens to be running another method that’s waiting on the same lock, a deadlock will occur. This can often be fixed simply by calling BeginInvoke instead of Invoke. Alternatively, you can release your lock before calling Invoke, although this won’t work if your caller took out the lock.
So be careful, locking is great but dangerous and as far as performance goes, locking is fast, nanoseconds fast.

Mutex, yey!
They basically do the same thing as locks but across processes. One common use case is to ensure that an application runs on a machine as a single instance.
Performance-wise mutex is slower than lock and it’s done in order of microseconds.

[code lang=”csharp”]
class Test
{
void Main()
{
// Naming a mutex makes it available computer-wide.
// Ensure you have a uniqure name for it.
using (var mutex = new Mutex(false, "nameOfTheMutex"))
{
// Wait a few seconds in case there is another
// application in the process of shutting down.
if (!mutex.WaitOne(TimeSpan.FromSeconds(3), false))
{
Console.WriteLine("Another instance is running.");
return;
}
RunMyApp();
}
}

void RunMyApp()
{
Console.WriteLine("Running. Press Enter to exit");
Console.ReadLine();
}
}
[/code]

Semaphores or in other words traffic lights.
They have a limited capacity defined by user, once full everyone has to wait outside until someone leaves.
They’re particularly useful when one wants to limit the maximum number of threads that can execute a piece of code at the same time.
Like mutex, a semaphore can span across multiple processes by naming it and thus limiting the number of applications that can run in parallel.
Below you can find an example for semaphore usage:

[code lang=”csharp”]
class Test
{
// define a capacity of three
private static Semaphore _semaphore = new Semaphore(0, 3);

void Main()
{
for (int i = 1; i <= 5; i++) new Thread(TestThread).Start(i);
}

void TestThread(object id)
{
Console.WriteLine(id + " tries to get in");
_semaphore.WaitOne();
Console.WriteLine(id + " is in!");
Thread.Sleep(1000 * (int)id);
Console.WriteLine(id + " leaves");
_semaphore.Release();
}
}
[/code]

That’s all, see you on the next posts on Thread Safety and Concurrent Collections!

Threading in C#: Part I

by Emanuel Scirlet | Oct 18, 2015 | .NET, C#

I’ve been asked so many times to address this topic but as you may already know it’s a bit complex to say the least and needs to be covered extensively since you can find use cases roughly everywhere. Threads are usually managed by a thread scheduler that ensures that all active threads are given CPU time and the threads that are waiting or blocked (for instance waiting for a resource to be freed or waiting for user input) do not consume any CPU time.

Typical use cases are those when you want to do multiple things at the same time, such as time expensive IO operations(download file, write in a file, read from database etc) or image processing etc and maintaining the rest of your application responsive. For example UI applications or servers are great examples for heavy thread usage. Now, as good as threads may be they can pose serious problems such as locking and memory leaks especially when used incorrectly. As I said earlier one of the most common issue is data sharing between threads or in other words how do the threads access a common resource without ending up in a deadlock. A deadlock is a situation where two(or more threads) are waiting for the other(s) to finish it’s job with the resource and as such it never does. So you have to be really careful when you’re sharing data between threads typically using a lock mechanism such as monitors, mutex or a semaphore to prevent that from happening. As for collections, C# provides you with thread safe collections: queues, stacks, dictionaries, you name it which all reside under
System.Collections.Concurrent namespace which it is a topic by itself that I’ll cover some other time.

Relevant namespaces for working with threads are System.Threading and System.Threading.Tasks. The first one is the old way of dealing with threading and it has been a while from .NET framework 2.0 while the latter one has been around only from .NET 4.0 and it somewhat simplifies threading. And then there is Task Parallel Library which is now the standard way.

Thread pool recycles threads and manages the number of threads that can be run in total such that once the maximum limit is reached, the jobs are queued and executed once a thread is freed. The Task Asynchronous Pattern(TAP) is an advanced and rather new mechanism that uses threads very efficiently and thus making applications much faster.

Using TPL(Task Parallel Library) starting new threads is extremely easy and resumes to a call like the one bellow:

[code lang=”csharp”]Task.Factory.StartNew(() => { Console.WriteLine("Hello"); });[/code]

Ofcourse I made use of lambdas there but basically you can use any delegate or method for that matter. Sure, you may ask yourself what if the method signature is not void, what if I want to get back some result. Sure you can do that:

[code lang=”csharp”]
// The <string> type argument for Task.Factory.StartNew
// is not necessary as it is inferred and you can remove it.
// Start the task executing:
Task<string> task = Task.Factory.StartNew<string>(() => GetMyCustomer());

// We can do other work here and it will execute in parallel:
RunSomethingElse();

// When we need the task’s return value, we query its Result property:
// If it’s still executing, the current thread will now block (wait)
// until the task finishes:
string customer = task.Result;
[/code]

Any unhandled exceptions are automatically rethrown when you query the task’s Result property and are wrapped in an AggregateException. However, if you fail to query its Result property (and don’t call Wait on the task) any unhandled exception will take the process down. You can find an example on how to handle such situations bellow:

[code lang=”csharp”]
Task<string> task = Task.Factory.StartNew(() => GetMyCustomer());
try
{
task.Wait();
}
catch (AggregateException aex)
{
foreach (Exception ex in aex.InnerExceptions)
Console.WriteLine(ex.Message);
}
[/code]

Alright, so you’ve learned some basics about threading in C# will continue this series as following:
Part II – More usages of threading(Timers, Dispatchers)
Part III – Concurrency, Concurrent Collections
Part IV – Task Asynchronous Pattern(TAP)