Shared-Variable Concurrency: A Proposal

In this talk I discuss the semantics of shared-variable concurrency, aka multi-threading. There are two well-known ways of managing concurrent threads: one either uses a

preemptive

or a

cooperative

scheduling discipline. In the former, a program, or more precisely its executable version, can be interrupted at any time during its execution by an external device, the scheduler, and the resources needed for execution are then given to another concurrent component for a while. This is perfect for executing concurrent

processes

, which do not share memory. In this case, the programmer does not have to care about the relative performance of the various processes in the system: this is the task of the scheduler. Unfortunately, it is very difficult to program multi-threaded applications with this model. The main difficulty is with

data races

, that is conflicting concurrent accesses to the memory. Although it is very easy to provide a formal “interleaving” semantics for preemptive multi-threading, this semantics usually does not coincide with what is actually implemented. In particular, the grain of atomicity is generally not preserved by the implementation, and a program may be time-sliced at some points of its execution which make no sense at the user level, and the consequence is that there is no clear semantics for the race conditions (see [14] for instance). It is therefore necessary to complement preemptive multi-threading with elaborate synchronization techniques, that require a real expertise from the programmer to be used (see [3]), and to design methods to analyze concurrent programs in order to make them “thread safe”, avoiding or detecting race conditions [1,6,11]. We shall not follow the preemptive approach in our proposal for shared-memory concurrency semantics.