Threads Module User's Guide : PART II Concurrency Packages : Chapter 3 The Threading Package : Definitions
Definitions
The following sections review basic definitions and concepts that are important to understanding the features of the Threading package.
Threads and Concurrency
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 multithread 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.
Threads and Memory
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.
Thread Safety
For information on thread safety in Rogue Wave products, please see Section 2.4.4, “Multithread Safety,” in the Essential Tools Module User’s Guide.