Multi Threading Related Definitions


To prevent people from talking of different things using the same term, this document provides the authoritative definitions used for the discussion of multi threading stuff on Of course, it is attempted to keep the terms synchron with common usage. However, since certain terms mean already different things to different people, it is necessary to provide a common basis of speech.


atomic access
For a data access to be atomic it has to be guarnateed that only one thread accesses a piece of data at the same time.
A deadlock occurs when two (or more) threads holding already a lock attempt locking another lock which unfortunately happens to be locked by the other thread. Here is an abstract example involving the two locks L1 and L2 and the two threads T1 and T2. At some point, T1 might hold lock L1 when trying to lock L2 which is already hold by T2. That is, executation of thread T1 is suspended until lock L2 is released. So far there is no problem. However, when thread T2 now attempts to lock L1 it is also suspended and neither thread will resume their executation because the locks they are waiting for will never be released. Consequently, both the threads are dead which might be acceptable depending on the application but also the resources protected by the locks have become inaccessible!
implementation of an interface
The implementation of an interface is just a piece of code which follows the requirements set up for an interface. This definition is deliberately kept somewhat vague to allow whatever technique is appropriate for the implementation.
An interface is a description of functions or methods applicable to entities. In particular, an interface is not necessarily directly reflect in any code, as is eg. the case for interfaces used in certain languages, eg. Java. There may be an abstract base class defined to reflect an interface but an interface might as well be defined by a set of requirements as are the interface to the various forms of iterators in the standard C++ library.
A lock is some facility used to prevent multiple threads from accessing some resource at the sime time.
Locking means to acquire some form of a lock. Trying to acquire a lock might result in suspending the current thread if the lock is already acquired by some thread.
A mutex or mutex lock or, in its complete form, mutual exclusion lock prevents a resource from being accessed from two different threads at the same time: Before accessing the resource a thread locks the mutex lock. If the mutex is already locked the thread will be suspended until the lock is released.

This definition does not yet cover all details associated with mutexes in general. In particular, it avoid the question on whether one thread can lock the mutex twice without blocking. For some people locking a resource twice from the same thread is permissable for others it is not. The position of the Boost Threading Library is currently open and will be subject to discussion when we know the exact requirements imposed by the idioms and techniques using mutexes.

Another aspect which seems to be open is the plural of "mutex": Is it "mutexes" or "muti". Since "mutex" has no Latin heritage it is "mutexes" in my opinion. If there is a strong point for the other alternative (or yet another one) we can go with this as well but we should not spent more than a minimum of time on this discussion and should later refrain from using both forms in discussions...

race condition
In a race condition two or more threads access the same data at the same time. Since modifications on data are not necessarily atomic, a race condition means that one or more threads see inconsistent data and that the data might be left in an inconsistent state when the threads are done with accessing the data.
A thread or, more precisely, a thread of execution is just that :-) This definition is definitely TODO...
thread local data
Each thread contain data which is local to this thread and can be accessed atomicly without any protection. For example, the objects allocated on the thread's stack are thread local. Note, however, that by informing other threads about the existance of such data, eg. by registering a reference to it with some data structure, thread locality might be removed!
thread safe
A program is called thread safe if during the execution of program there can never be a race condition or one of the effects of preventing race conditions like eg. a deadlock. That is, despite the existance of multiple threads during the executation of the program, the data processed stays consistent and the program performs the task it is designed for (well, at least it does not fail to meet this task due to problems related in some form to threads).
thread synchronization
Thread synchronization refers to coordinating threads to play together. Normally this means that it is prevented that two threads access the same resource at the same time. That is the threads are not synchronized in the form that one thread waits until another thread has reached a certain point of execution. This term seems to be a bit backwards...

Copyright © 2000 Dietmar Kühl, Phaidros Software AG (