Deadlocks

In the context of multithreading, a deadlock occurs when two different processes are waiting on the other to finish, effectively making it impossible for any of them to finish to begin with.

This can happen when both processes are sharing a resource. If Thread B wants a resource that Thread A is holding, and Thread A wants a resource that Thread B has, both processes will be waiting for each other to finish, sitting in a perpetual deadlock state. Figure 1-1 illustrates how this might occur.

A schematic diagram depicts the execution flow of Threads A and B, which consists of resource C with the correct symbol at Thread A and resource D with the incorrect symbol and vice versa of symbols at Thread B.

Figure 1-1 illustrates how Thread A may try to access Resource C and Resource D, one after the other, and how Thread B may try to do the same but in different order. In this example, the deadlock will happen rather soon, because Thread A will get hold of Resource C while Thread B gets hold of Resource D. Whoever needs each other’s resource first will cause the deadlock .

Despite how simple this problem looks, it is the culprit of a lot of bugs in a lot of multithreaded software. The simple solution would be to prevent each process from attempting to access a busy resource. But how can this be achieved?

Solving the Deadlocking Problem

The deadlock problem has many established solutions. Mutex and Semaphores being the most used ones. There is also Inter-process communication through pipes, but we will not talk about it because it goes beyond a single program.

Mutex

Mutex is short for Mutually exclusive lock (or flag). A mutex will signal other processes that a process is currently using some resource by adding a lock to it and preventing other processes from grabbing until that lock is freed. Ideally, a process will acquire a lock to all the resources it will need at once, even before using them. This way, if Thread A needs Resource C and Resource D, it can lock them before Thread B tries to access them. Thread B will wait until all the locks are freed before attempting to access the resources itself. Figure 1-2 illustrates how this is done.

A schematic diagram depicts the execution flow of Thread A and B, which consists of Resources C and D with the lock symbol, continue execution with locked resources, and wait for resources to get unlocked with the refresh symbol.

Keep in mind that in this specific situation, it means that Thread A and Thread B, while multithreaded, will not run strictly at the same time, because Thread B needs the same resources as Thread A and it will wait for them to be free. For this reason, it is important to identify tasks that can be run in parallel before designing a multithreaded system.

Semaphores

A Semaphore is a type of lock, very similar to a mutex . With this solution, a task will acquire a lock to a resource. Any other tasks that arrive and need that resource will see that the resource is busy. When the original thread frees the resources, it will signal interested parties that the resource is free, and they will follow the same process of locking and signaling as they interact with the resource.

Mutex and Semaphores sound similar, but the key difference lies in what kind of resource they are locking, and if you ever find yourself in a situation in which you need to decide what to protect (you won’t find such a case when using async/await), it is important to think about what makes sense in your use case. In general, a mutex can be used to protect anything that doesn’t have any sort of execution on its own, such as files, sockets, and other filesystem elements. Semaphores can be used to protect execution in your program itself such us shared code execution paths. These can be mutating functions or classes with shared state. There may be cases in which executing a function by more than one thread will have unintended consequences, and semaphores are a good tool for that. For example, a function that writes a log to disk may be protected with a semaphore because if multiple processes write to the log at the same time, the log will become corrupted for the end user. Whoever has a semaphore to the logging function needs to signal the other interested parties that it is free so they can continue their execution.

A rule of thumb is to always add a timeout whenever a semaphore is acquired and let processes timeout if they take too long. If this is acceptable in the context of your program (no data corruption can occur, or there can be no other unintentional consequences to canceling tasks), consider adding a timeout so the semaphore is free again after a certain period.

The use of semaphores will allow threads to synchronize, as they will be able to coordinate the resources amongst each other so they both have their fair usage of them.

Starvation

The Starvation problem happens when a program is stuck in a state of perpetually waiting for resources to do some work but never receiving them. Figure 1-3 illustrates this problem.

A circular model represents the five people symbol outside the circle, which resembles a dining table with five forks and plates.

Figure 1-3 describes what is known as the dining philosophers problem, and it is a classical representation of the starvation problem .

The problem illustrates five philosophers who want to eat at a shared table. All of them have their own dishes, and there are five forks. However, each philosopher needs two forks to eat. This means that only two philosophers get to eat, and only the ones who are not sitting directly next to each other. When a philosopher is not eating, he puts both forks down. But there can be a situation in which a philosopher decides to overeat, leaving another to starve.

Luckily for low-level multithreading developers, it’s possible to use the semaphores we talked about above to solve this problem. The idea is to have a semaphore that keeps track of the used forks, so it can signal another philosopher when a fork is free to be used.

Race Conditions

Likely the multithreading problem most developers are familiar with, Race Conditions are very similar to deadlocks , with the exception that they can cause data or memory corruption that will lead to other unpleasant consequences. When we are dealing with multithreading, it isn’t inherently a bad thing that two processes are reading data at the same time. If the resource is read-only, there is no harm. However, if the processes can modify or update the resource in any way, the processes will continually overwrite the data another process just wrote, and this will eventually lead to reading and writing corrupted data. If the resource in question is user data, we will have unhappy users. If the resource is provided by the OS, we can cause other unwanted consequences and eventually reach one of the multithreading issues such as deadlocks . Figure 1-4 illustrates this pitfall.

A schematic diagram depicts the history log in the center, with Thread A and Thread B pointing towards it.

If a history log is being written to by any threads with no control, events may be registered in a random order, and one thread may override the line another thread just wrote. For this reason, the History Log should be locked at the writing operation. A thread writing to it will get a mutex to the log, and it will free it after it’s done using it. Anyone else needing to write to the log will be waiting until the lock is freed.

Deadlocks and race conditions are very similar. The main difference, in deadlocks, is we have multiple processes waiting for the other to finish, whereas in race conditions we have both processes writing data and corrupting it because no processes know that the resource in question is being used by someone else. This means that the solutions for deadlocking also apply to race conditions , so just block your resource with a mutex or semaphore to guarantee exclusive access to the resource by one process only. This is called an Atomic Operation.

Livelocks

There is a saying in life that goes “you can have too much of a nice thing.” It is important to understand that throwing locks willy-nilly is not a solution to all multithreading problems. It may be tempting to identify a multithreading issue, throw a mutex at it, and call it a day. Unfortunately, it’s not so easy. You need to understand your problem and identify where the lock should go.

Similarly, this problem can occur when processes are too lenient with the conditions under which they can release and attain resources. If Thread A can ask Thread B for a resource and Thread B complies without any thought, and Thread B can do the same to Thread A, it may happen that eventually they will not be able to ask each other for the resource back because they can’t even get to that point of the execution.

This is a classic example in real life. Suppose you are walking towards a closed door and someone else arrives to it at almost the same time as you. You may want to let the other person go in first, but they may tell you that you should go first instead. If you are familiar with this awkward feeling, you know what a livelock feels like for our multithreaded programs.

pthreads

pthreads (POSIX Threads) are the implementation of a standard defined by the IEEE.¹ The POSIX part of their name (Portable Operating System Interface) tells us that they are available in many platforms, and not only on Apple’s operating systems. Traditionally, hardware vendors used to sell their products offering their own, proprietary multithreading APIs. Thanks to this standard you can expect to have a familiar interface in multiple POSIX systems. The great advantage of pthreads is that they are available in a wide array of systems if they are POSIX compliant, including some Linux distributions.

The disadvantage is that pthreads are purely written in C. C is a very low-level programming language, and it is a language that is slowly fading from the knowledge base of many developers. The younger they are, the less likely they are to know C. While I do not expect C to disappear any time soon, the truth is that it’s very hard to find iOS developers who know the C programming language, let alone use it correctly. pthreads are the lowest-level multithreading APIs we have available, and as such they have a very steep learning curve. If you opt to use pthreads , it’s because you have highly specific needs to control the entire multithreading and concurrency flow, though most developers will not need to drop down to these levels often, if at all. You will be launching threads and managing resources such as mutex more manually. If you are familiar with pthreads because you worked with them in another platform, you can use your knowledge here too, but be aware future programmers who will maintain your code may not be familiar with either pthreads or the C language itself.

NSThreads

NSThread is a Foundation object provided by Apple. They are low level, but not as low level as pthreads. Since they are foundation objects, they offer an Objective-C interface . Offering this interface will expose the tool to many more developers, but as time goes on, less iOS developers are likely to know Objective-C. In fact, it’s entirely possible to find iOS developers with some years of experience who have never had to use this language before, although it can be used in Swift as well.

If you want to work with multithreading, you will end up creating multiple NSThread objects, and you are responsible for managing them all. Each NSThread object has properties you can use to check the status of the thread, such as executing, cancelled, and finished. You can set the priority of each thread which is a very real use case in multithreading. You can even get the main thread back and ask if the current thread is the main thread to avoid doing expensive work on it.

Just like pthreads , most developers will not have to drop down to this level often, if at all.

The Grand Central Dispatch (GCD)

Looks familiar? This is one of the most famous calls on the GCD because it allows you to defer some work quickly and painlessly to be done on the main thread . This call is likely to be found after a subclass of URLSessionTask finishes some work and you want to update your UI, for example.

Listing 1-4 shows hypothetical code that would retrieve a user’s data and their favorite movies from somewhere. This usage is very typical with the GCD . When your work requires you to do more than one call that depends on the task of another, your code starts looking like a pyramid of doom . There are ways to solve this (like creating different functions for fetching the user data and their movies), but it’s not entirely elegant.

Despite its drawbacks, the GCD is a very popular way to create concurrent and multithreaded code. It has a lot of protections in place already for you, so you don’t have to be an expert in the theory of multithreading to avoid making mistakes. The samples we saw here only show a very tiny bit of functionality it offers. While the tool is high level enough to save you from many headaches, it exposes a lot of lower level functionality, and it gives you the ability to directly interact with some primitives such as semaphores .

Finally, this technology is open source, so it’s possible to find in platform outside of anything Apple develops. The GCD is big, and talking about its features would go outside the scope of this book, but be aware that it has been in use for a very long time and it’s possible you are going to see some advanced techniques with it in your career.

The NSOperation APIs

Sitting at a higher level than the GCD , the NSOperation APIs are a high-level tool to do multithreading. Despite the fact they are not as widely known as the GCD, they found their place in some parts of the SDK. For example, the CloudKit APIs make use of this technology.

Using these APIs is very simple. You begin by creating an OperationQueue. This queue’s responsibility is to execute any task you add to it. You can also give it a name to refer to it later, or if you need to search for it.

In Listing 1-5 , we create two tasks (in this case, instances of BlockOperation – the original API is in Objective-C, so in Swift, it’s a closure), from1To10 and from11To20. They begin executing as soon as they are submitted to the queue via the OperationQueue.addOperation call. In this example, you will see that the numbers get printed almost in an interleaved manner. The results you get are going to be different each time you run the program.

It’s very easy to run multiple tasks at once, but what if you want to run one task after the other because one of them depends on the data of another, or simply because it makes sense to do so?

It’s worth to note that while you don’t have thread management abilities with this framework, you can check the status of each operation (isCancelled, isFinished, etc.), and you can cancel your operations at any time (by calling cancel on it). If an operation gets cancelled, other operations that depended on it will also be cancelled.

Using the NSOperation APIs is simple, as you have evidenced. It can still be a great tool when you have simple multithreaded needs.