| 
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...
      
  
  
 
 |