Mastering concurrent computing through sequential thinking

Abstract

Concurrency, the art of doing many things at the same time is slowly becoming a science. It is very difficult to master, yet it arises all over modern computing systems, both when the communication medium is shared memory and when it is by message passing. Concurrent programming is hard because it requires to cope with many possible, unpredictable behaviors of communicating processes interacting with each other. Right from the start in the 1960s, the main way of dealing with concurrency has been by reduction to sequential reasoning. We trace this history, and illustrate it through several examples, from early ideas based on mutual exclusion, passing through consensus and concurrent objects, until today ledgers and blockchains. We conclude with a discussion on the limits that this approach encounters, related to fault-tolerance, performance, and inherently concurrent problems..

Distributed Computability

“…Starvation-freedom is a stronger progress condition, namely it states that if any process invokes an operation on a shared object, its invocation will succeed. Deadlock-free and starvation-free mutual exclusions are a classical techniques used to protect accesses to shared objects [73].…”

On the weakest information on failures to solve mutual exclusion and consensus in asynchronous crash-prone read/write systems

“…As a simple example, when, to cope with process crashes, one has to duplicate a state machine on a set of server processes with one copy per server, in order to prevent the copies from diverging the ones from the others, the servers have to agree on a single order to apply the state machine operations (or commands) on their individual copies [21,29,31]. In short, while resources are physical objects managed with mutual exclusion, state machines are digital objects managed with consensus [27].…”