Editing Thread safety (section)

==Implementation approaches==
Listed are two classes of approaches for avoiding [[race condition#Computing|race conditions]] to achieve thread-safety.

The first class of approaches focuses on avoiding shared state and includes:
; [[Reentrant (subroutine)|Re-entrancy]]<ref>{{cite web |title=Reentrancy and Thread-Safety &#124; Qt 5.6 |url=https://doc.qt.io/qt-5/threads-reentrancy.html |access-date=2016-04-20 |publisher=Qt Project}}</ref>: Writing code in such a way that it can be partially executed by a thread, executed by the same thread, or simultaneously executed by another thread and still correctly complete the original execution. This requires the saving of [[state (computer science)|state]] information in variables local to each execution, usually on a stack, instead of in [[static variable|static]] or [[global variable|global]] variables or other non-local state. All non-local states must be accessed through atomic operations and the data-structures must also be reentrant.
; [[Thread-local storage]]: Variables are localized so that each thread has its own private copy. These variables retain their values across [[subroutine]]s and other code boundaries and are thread-safe since they are local to each thread, even though the code which accesses them might be executed simultaneously by another thread.
; [[Immutable object]]s: The state of an object cannot be changed after construction. This implies both that only read-only data is shared and that inherent thread safety is attained. Mutable (non-const) operations can then be implemented in such a way that they create new objects instead of modifying the existing ones. This approach is characteristic of [[functional programming]] and is also used by the ''string'' implementations in Java, C#, and Python. (See [[Immutable object]].)

The second class of approaches are synchronization-related, and are used in situations where shared state cannot be avoided:
;[[Mutual exclusion]]: Access to shared data is ''serialized'' using mechanisms that ensure only one thread reads or writes to the shared data at any time. Incorporation of mutual exclusion needs to be well thought out, since improper usage can lead to side-effects like [[deadlock (computer science)|deadlock]]s, [[livelock]]s, and [[resource starvation]].
; [[Linearizability|Atomic operations]]: Shared data is 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 is always kept in a valid state, no matter how other threads access it. Atomic operations form the basis of many thread locking mechanisms, and are used to implement mutual exclusion primitives.