What are threads?

UNIX System V Release 4.2 MP (SVR4.2 MP) and UnixWare 2.0 provide vastly expanded capabilities for concurrent programming via the Threads Library. These capabilities include:

• Facilities to define multiple ``threads of control'' to be run concurrently within a single process. Each ``thread'' is a set of instructions that is itself sequential but can be executed concurrently with other threads.

• A new, rich set of software mechanisms for coordinating and synchronizing the activities of the process' threads. These include:

  • mutual exclusion locks (``mutexes''); both recursive and not; both blocking and spinning.

  • reader-writer locks

  • counting semaphores (not the IPC semaphore system calls)

  • condition variables

  • barriers

• Features to control the level of concurrency and the scheduling of threads.

• Underlying operating system kernel support that enables the library to provide true concurrency (on multi-processor architectures), not just logical concurrency for threads.

General characteristics of threads programming:

• Each thread starts executing at a programmer-specified address of a function.

  • A given, common function can be the starting point for several unique threads.

• A thread has many features that are analogous to process features. For example,

  • Each thread is an individually schedulable entity.

  • Threads can be preempted; consequently, a thread cannot assume uninterrupted access to common data unless special synchronizing arrangements (for example, locking) are made.

  • Threads execute logically in parallel, exhibit logical concurrency and possibly true concurrency.

  • A thread will go through many states during its lifetime such as:

    • executing

    • ready to run but not currently executing

    • waiting for some resource

    • terminated thread with unreported exit status

    • stopped from running

  • Threads can receive signals; consequently, asynchronous programming is still possible (see ``Threads and signals'').

  • In this implementation, most of the features of the Threads Library are implemented by user-level library code that is dynamically linked with the application program at run time. The underlying operating system kernel is not aware of the threads of a process.

  • The operating system kernel supports a scheduling abstraction called the ``lightweight process'' (LWP). An LWP is not the same as a thread. It is a facility that is used by the Threads Library to provide true concurrency for threads (see ``Managing threads concurrency'').

  Each thread of the process has access to all of the resources of the process including:

  • The entire address space.

    Any thread can access any memory location in the process. By using threads for concurrency, the programmer sacrifices the address space protection that the operating system maintains (with support of hardware features) between processes. A wild pointer in one thread can easily corrupt memory used by another thread.

    On the other hand, thread-to-thread data sharing is easy and efficient. By default, all data is available to all threads. Thread-to-thread communication avoids the system call overhead and typical data copying of process-to-process communications.

  • Resources maintained by the operating system, including:

    • Open files, file pointer offsets, file/record locks, and current directory.

    • Access rights (to files, IPC facilities, and so on) and Enhanced Security privileges.

    • Resource limits such as ``ulimit'', ``umask'', and file descriptor limit.

  • Process identity (such as process ID number, parent process ID, process group number)

  The features that are unique to each thread include:

  • Program context (that is, register values)

  • Stack

  • Scheduling information (such as scheduling class, current priority)

  • Timers

  • Signal handling

    Actually, some signal handling features are maintained per thread and some are maintained at the process level. The relationship between the two (and how to use them) will be discussed later (see ``Threads and signals'').

  • Thread ID number and thread-private data.
  On the whole, there is a much more intimate relationship between the threads of a process than between processes of an application. This gives the programmer much greater flexibility and potentially better performance.

  • With this intimacy there is a greater potential for introducing subtle errors and that implies a greater demand on the programmer's skill to produce correct code.

  • Moreover, the proper design of a concurrent program requires certain disciplines that do not often arise in sequential programming. For example, inappropriate use of the Threads Library facilities for synchronizing threads may result in a program that is incorrect, inefficient, or both.

The facilities of the Threads Library are well-suited for medium- to coarse-grained concurrency. It may be inappropriate to use the facilities of the Threads Library if:

• the scale of concurrent tasks cannot be efficiently expressed in terms of a function.

• the task to be performed concurrently is an entire program (perhaps an existing program). It is probably more reliable to use fork(2) or exec(2) (or even the shell).

• the task to be performed concurrently is extremely small scale (loop level). In this case, the Threads Library may entail too much overhead. Parallelizing compilers exist for this scale of concurrency.

Threads illustrated

``Overview of threads'' illustrates the relation of threads to LWPs to processes to processors. The terms ``multiplexed threads'' and ``bound threads'' are discussed elsewhere in this section.

Overview of threads