Learning Concurrent Programming in Scala: Practical Multithreading in Scala , Second Edition

In modern, pre-emptive, multitasking operating systems, the programmer has little or no control over the choice of processor on which the program will be executed. In fact, the same program might run on many different processors during its execution and sometimes even simultaneously on several processors. It is usually the task of the Operating System (OS) to assign executable parts of the program to specific processors--this mechanism is called multitasking, and it happens transparently for the computer user.

Historically, multitasking was introduced to operating systems to improve the user experience by allowing multiple users or programs to use resources of the same computer simultaneously. In cooperative multitasking, programs were able to decide when to stop using the processor and yield control to other programs. However, this required a lot of discipline on the programmer's part and programs could easily give the impression of being unresponsive. For example,...

In this section, we will study inter-thread communication using the synchronized statement in more detail. As we saw in the previous sections, the synchronized statement serves both to ensure the visibility of writes performed by different threads, and to limit concurrent access to a shared region of memory. Generally speaking, a synchronization mechanism that enforces access limits on a shared resource is called a lock. Locks are also used to ensure that no two threads execute the same code simultaneously; that is, they implement mutual exclusion.

As mentioned previously, each object on the JVM has a special built-in monitor lock, also called the intrinsic lock. When a thread calls the synchronized statement on an x object, it gains ownership of the monitor lock of the x object, given that no other thread owns the monitor. Otherwise, the thread is blocked until the monitor is released. Upon gaining ownership of the monitor, the thread can witness the memory writes...

The JVM offers a more lightweight form of synchronization than the synchronized block, called volatile variables. Volatile variables can be atomically read and modified, and are mostly used as status flags; for example, to signal that a computation is completed or canceled. They have two advantages. First, writes to and reads from volatile variables cannot be reordered in a single thread. Second, writing to a volatile variable is immediately visible to all the other threads.

In the following example, we search for at least one ! character in several pages of the text. Separate threads start scanning separate pages p of the text written by a person that is particularly fond of a popular fictional hero...

While we were never explicit about it throughout this chapter, we have actually defined most of the JMM. What is a memory model in the first place?

A language memory model is a specification that describes the circumstances under which a write to a variable becomes visible to other threads. You might think that a write to a variable v changes the corresponding memory location immediately after the processor executes it, and that other processors see the new value of v instantaneously. This memory consistency model is called sequential consistency.

As we already saw in the ThreadSharedStateAccessReordering example, sequential consistency has little to do with how processors and compilers really work. Writes rarely end up in the main memory immediately; instead, processors have hierarchies of caches that ensure a better performance and guarantee that the data is only eventually written to the main memory. Compilers are allowed to use registers to postpone or avoid memory...

In this chapter, we showed how to create and start threads, and wait for their termination. We have shown how to achieve inter-thread communication by modifying the shared memory and by using the synchronized statement, and what it means for a thread to be in a blocked state. We have studied approaches to prevent deadlocks by imposing the ordering on the locks and avoided busy-waits in place of guarded blocks. We have seen how to implement a graceful shutdown for thread termination and when to communicate using volatiles. We witnessed how the correctness of a program can be compromised by undesired interactions known as race conditions as well as data races due to the lack of synchronization. And, most importantly, we have learned that the only way to correctly reason about the semantics of a multithreaded program is in terms of happens-before relationships defined by the JMM.

The language primitives and APIs presented in this section are low-level; they are the basic building blocks...

In the following set of exercises, you are required to implement higher-level concurrency abstractions in terms of basic JVM concurrency primitives. Some of these exercises introduce concurrent counterparts of sequential programming abstractions, and, in doing so, highlight important differences between sequential and concurrent programming. The exercises are not ordered in any particular order, but some of them rely on specific content from earlier exercises or this chapter: