How to define threadsafe?

Question

Threadsafe is a term that is thrown around documentation, however there is seldom an explanation of what it means, especially in a language that is understandab

Answer 1

Tread-safe code is code that won't fail because the same data was changed in two places at once. Thread safe is a smaller concept than concurrency-safe, because it presumes that it was in fact two threads of the same program, rather than (say) hardware modifying data, or the OS.

Answer 2

G'day,

A good place to start is to have a read of the POSIX paper on thread safety.

Edit: Just the first few paragraphs give you a quick overview of thread safety and re-entrant code.

HTH

cheers,

Answer 3

I would say to understand thread safe, start with understanding difference between thread safe function and reentrant function.

Please check The difference between thread-safety and re-entrancy for details.

Answer 4

Multithreading leads to non-deterministic execution - You don't know exactly when a certain piece of parallel code is run.

Given that, this wonderful multithreading tutorial defines thread safety like this:

Thread-safe code is code which has no indeterminacy in the face of any multithreading scenario. Thread-safety is achieved primarily with locking, and by reducing the possibilities for interaction between threads.

This means no matter how the threads are run in particular, the behaviour is always well-defined (and therefore free from race conditions).

Answer 5

A thread safe function / object (hereafter referred to as an object) is an object which is designed to support multiple concurrent calls. This can be achieved by serialization of the parallel requests or some sort of support for intertwined calls.

Essentially, if the object safely supports concurrent requests (from multiple threads), it is thread safe. If it is not thread safe, multiple concurrent calls could corrupt its state.

Consider a log book in a hotel. If a person is writing in the book and another person comes along and starts to concurrently write his message, the end result will be a mix of both messages. This can also be demonstrated by several threads writing to an output stream.

Answer 6

A particularly valuable aspect of the term is that it lies on a spectrum of concurrent behavior, where thread safe is the strongest, interrupt safe is a weaker constraint than thread safe, and reentrant even weaker.

In the case of thread safe, this means that the code in question conforms to a consistent api and makes use of resources such that other code in a different thread (such as another, concurrent instance of itself) will not cause an inconsistency, so long as it also conforms to the same use pattern. the use pattern MUST be specified for any reasonable expectation of thread safety to be had.

The interrupt safe constraint doesn't normally appear in modern userland code, because the operating system does a pretty good job of hiding this, however, in kernel mode this is pretty important. This means that the code will complete successfully, even if an interrupt is triggered during its execution.

The last one, reentrant, is almost guaranteed with all modern languages, in and out of userland, and it just means that a section of code may be entered more than once, even if execution has not yet preceeded out of the code section in older cases. This can happen in the case of recursive function calls, for instance. It's very easy to violate the language provided reentrancy by accessing a shared global state variable in the non-reentrant code.