|
Multi Threading Related Definitions
Introduction
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
www.boost.org. 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.
Definitions
-
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.
-
deadlock
-
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.
-
interface
-
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.
-
lock
-
A lock is some facility used to prevent multiple
threads from accessing some resource at the
sime time.
-
locking
-
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.
-
mutex
-
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.
-
thread
-
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...
|