3.2 Definitions

The following sections review basic definitions and concepts that are important to understanding the features of the Threading package.

These terms refer to the concurrency aspects of threading:

Thread, or thread-of-control-A sequence of instructions that can be executed on a processor. A thread is associated with, or possesses, an execution context, typically consisting of a program counter and a private stack.

Process-A program that is loaded into memory and is prepared for execution. Each process has its own private address space, and starts with a single thread. Many system resources, such as file handles and network connections, are allocated and bound on a per process basis. All threads within a process share the private address space and system resources of that process.

Concurrent-Two or more threads in one or more processes that are in progress at the same time. A single processor system can support concurrency by switching execution between two or more threads. A multi-processor system can support parallel concurrency by executing a separate thread on each processor.

Multithreaded-A class, library, or application that uses two or more threads in one or more processes for some period during its execution.

Multithread-hot or MT-hot-A class, library, or application that creates additional threads to accomplish its task. Labeling something as MT-hot is a warning that inclusion of a such a class or library into a product can require that the class or library-user use multi-thread protection or synchronization within other portions of the product. The Threading package creates no threads of its own and is therefore not considered an MT-hot product.

These terms refer to the memory aspects of threading:

Shared variables-All threads within the same process share the address-space of that process. Globally-named and static variables are implicitly shared among all threads within a process. Object instances dynamically created on the heap or automatically created on the stack can be explicitly shared by passing references or addresses between threads.

Local variables-Each thread possesses its own stack within the process address space. Non-static, function-scope variables are automatically allocated and constructed in a thread's stack as their definitions are encountered. When the thread's execution flow causes the variables to go out of scope, they are destructed and de-allocated. These automatic object instances are generally considered to be local to the thread, although they can still be accessed by other threads if shared by reference or address.

Thread-local or thread-specific storage-The life span and accessibility of a local variable on a thread's stack is limited by its scope (it only exists within the scope of the function where it was declared, for example). Also global instances are always shared between all threads. Therefore, another kind of storage is required when threads need to maintain a thread-local instance of some object, but also need to share this instance between the functions being executed by the thread. This capability is provided by thread-local storage (also called thread-specific storage). Thread-local storage is an alternative form of storage maintained and accessed on a per-thread basis, but with a life-span that is independent of normal stack scope. Thread-local storage can also possess a global name that is shared among all functions within a thread.

These terms refer to the safety aspects of threading:

Unsafe-An unsafe routine, class, or library is not safe to use in a multi-threaded application unless the application arranges for only one thread at a time to access or execute within that routine, class, or library. Unsafe routines, classes, or libraries often contain global and static data that are not protected. Unsafe libraries or classes might contain some routines that are safe, but the library or class as a whole has been deemed to be unsafe.

Safe-A safe routine, class, or library can be accessed or executed from within a multi-threaded application. Safe objects are reentrant and protect their internal global or static data from multi-threaded corruption. A safe object does not necessarily support any concurrency. A safe routine, class, or library might require users to perform their own global or local locking and unlocking of objects in order to achieve some level of concurrency. This level of thread safety is sometimes referred to as MT-safe: level 1.

MT-safe-An MT-safe routine, class, or library is fully prepared for multi-threaded access and execution. MT-safe objects are reentrant, protect their internal global or static data, and have a reasonable level of concurrency. An MT-safe class or library implies that individual operations can be performed safely without user locking and unlocking. However, an MT-safe class or library might still require the user to perform external synchronization or locking in situations where several individual operations must be combined and treated as a single atomic operation (testing for, and reading the contents of a queue, for example). This level of thread safety is sometimes referred to as MT-safe: level 2.