# (concise?) definition of thread safety

Wikipedia has the following definition:

Thread safety is a computer programming concept applicable in the context of multi-threaded programs. A piece of code is thread-safe if it only manipulates shared data structures in a manner that guarantees safe execution by multiple threads at the same time. There are various strategies for making thread-safe data structures.[1][2] ... and so on ( http://en.wikipedia.org/wiki/Thread-safety )

However, precise definition seems not to be simple. A naive approach is:

Thread-safety means that program's observable behavior does not depend on eligible thread scheduling order.

Still, it may be incorrect definition. Say, threads may log messages into log file, and reodering of log messages may be OK. So program observable behavior may vary, but the program may be considered thread-safe.

Probably, we need to specify allowed types of different program observable behaviors while being thread-safe.

Yet another complication: there may be thread-safe (or thread-unsafe) code, not the whole program. (One may think about compositional properties of (non-)thread-safe code and so on)

So, the questions are: how to precisely define thread safety? Is there concise definition? What work was done to define thread safety?

• I believe this is what you are looking for. The stronger the guarantees the harder it is to implement (maybe even impossible in the absence of some assumptions). So there are several relaxations that are easier to implement, but weaker relaxations may be more appropriate to some applications than others. Feb 7 '12 at 22:23
• You might also want to review the literature on the relatively new field of transactional memory. Feb 8 '12 at 0:54
• Please remember that cstheory is for theoretical computer science. Although theoretical software engineering and formal methods questions are welcome on cstheory, Software Engineering would be a better place to ask software engineering questions of if you are looking for practical answers. Feb 8 '12 at 17:23
• @Kaveh Sure. But let me explain. Practical aspects of a problem serve me as guides to choose "what theory I need to learn now, and what to defer for future". Is programmers.stackexchange.com a proper place to ask a question like "what papers I need to read and what papers I need to look at"? [Next, although I have chosen vzn's answer, I have voted up Sam Tobin-Hochstadt's answer.] Feb 9 '12 at 13:06
• @user1123502, software engineers also read and write papers. :) Feb 9 '12 at 14:13

arguably thread safety is a more abstract concept that would be difficult to formally/strictly define although there are some definitions with variations in the literature depending on the specific context.

thread safety also fits in highly with "best practices" and "design patterns". loosely defined, a thread safe program does not have bugs related to multithreading. this definition is intentionally vague because defining thread safety exactly would almost be as difficult as defining what constitutes a "bug".

heres another way to approach it. generally thread count $n$ is the variable in multithreaded system. thread safety means that the code "runs the same" or "gets the same results" regardless of $n$ including $n=1$, or for both $n=1$ and $n>1$.

here is a taxonomy of "degrees of thread safety" outlined by a java practitioner/authority/author that would probably be general across languages:

the general trend is to create high level abstraction libaries for multithreading (see intel threadable building blocks, java concurrent library) and use the higher level object abstractions instead of lower-level language features. (eg in java this would be "synchronized" code, special thread-related keywords like "transient" etcetera).

there is a lot of research in this area in papers & one paper I recall attempted to create and prove that a simple system built out of "pipes and filters" design pattern (similar to unix) was both thread safe and that many alternatives were likely not threadsafe, but cant locate it at the moment.

• your taxonomy ( ibm.com/developerworks/java/library/j-jtp09263/index.html ) is something that I expected to find as a "short-term" answer; other answers are also usefull and interesting, but they are "long-term" ones Feb 8 '12 at 3:44
• fyi the paper I may be thinking of might be on CSP
– vzn
Aug 8 '12 at 15:26
• I hope Santa brought you a brand new Shift key. Dec 25 '20 at 10:18

There has been a lot of work on this, usually under the heading of "memory models". See, for example:

• unfortunately there are many ways to create non-threadsafe thread operations in java.
– vzn
Feb 7 '12 at 23:51
• The Boehm and Adve paper is dated to 2008. Does c++11 standard follow the paper? May I read the paper as an "explanation of c++11 standard concurrency model"? Feb 8 '12 at 3:54
• @vzn it is interesting to look at non-threadsafe thread operations in java; it is very interesting and instructive to find out that "something obvious" is really not obvious, but wrong; do you have links? Feb 8 '12 at 4:03
• there are some excellent refs on java concurrency. see eg java concurrency in practice book. this ref popped up specifically looking for thread "antipatterns" defining a catalog of programming anti-patterns for concurrent java by bradbury et al
– vzn
Feb 8 '12 at 5:45