is a computer programming
concept applicable in the context of multi-threaded
programs. A piece of code is thread-safe
if it functions correctly during simultaneous execution by multiple threads. In particular, it must satisfy the need for multiple threads
to access the same shared data, and the need for a shared piece of data to be accessed by only one thread at any given time.
Thread safety is a key challenge in multi-threaded programming. It was once only a concern of the operating system programmer but since the late 1990s has become a commonplace issue. In a multi-threaded program, several threads execute simultaneously in a shared address space. Every thread has access to virtually all the memory of every other thread. Thus the flow of control and the sequence of accesses to data often have little relation to what would be reasonably expected by looking at the text of the program, violating the principle of least astonishment. Thread safety is a property aimed at minimizing surprising behavior by re-establishing some of the correspondences between the actual flow of control and the text of the program.
It is not easy to determine if a piece of code is thread-safe or not. However, there are several indicators that suggest the need for careful examination to see if it is unsafe:
A subroutine is reentrant, and thus thread-safe, if it only uses variables from the stack, depends only on the arguments passed in, and only calls other subroutines with similar properties. This is sometimes called a "pure function", and is much like a mathematical function.
There are a few ways to achieve thread safety: Re-entrancy
: Writing code in such a way that it can be partially executed by one task, reentered
by another task, and then resumed from the original task. This requires the saving of state
information in variables local to each task, usually on its stack, instead of in static
variables. Mutual exclusion
: Access to shared data is serialized
using mechanisms that ensure only one thread reads or writes the shared data at any time. Great care is required if a piece of code accesses multiple shared pieces of data—problems include race conditions
, and various other ills enumerated in many operating systems
textbooks. Thread-local storage
: Variables are localized so that each thread has its own private copy. These variables retain their values across subroutine
and other code boundaries, and are thread-safe since they are local to each thread, even though the code which accesses them might be reentrant. Atomic operations
: Shared data are accessed by using atomic operations
which cannot be interrupted by other threads. This usually requires using special machine language
instructions, which might be available in a runtime library
. Since the operations are atomic, the shared data are always kept in a valid state, no matter what other threads access it. Atomic operations
form the basis of many thread locking mechanisms.
One approach to making data thread-safe that combines several of the above elements is to make changes to a private copy of the shared data and then atomically
update the shared data from the private copy. Thus, most of the code is concurrent
, and little time is spent serialized