Thread-safe

From Wikipedia, the free encyclopedia

Thread-safety 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.

1 Determining thread safety
2 Achieving thread-safety
3 See also
4 External links

[edit] Determining thread safety

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:

accessing global variables or the heap
allocating/freeing resources that have global limits (files, sub-processes, etc.)
indirect accesses through handles or pointers
any visible side-effect (e.g., access to volatile variables in the C programming language)

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.

[edit] Achieving thread-safety

There are a few ways to achieve thread-safety:

re-entrancy: Basically, writing code in such a way that it can be interrupted during one task, reentered to perform another task, and then resumed on its original task. This usually precludes the saving of state information, such as by using static or global variables.
mutual exclusion: Access to shared data is serialized using mechanisms that ensure only one thread is accessing 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, deadlocks, livelocks, starvation, 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. The variables retain their values across subroutine and other code boundaries, and the code which accesses them might not be reentrant, but since they are local to each thread, they are thread-safe.
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 order threads access it. Atomic operations form the basis of many thread locking mechanisms.

A commonly used idiom combines these approaches:^{[citation needed]}

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.