User-Level Native Thread Primitives (GThread) Library White Paper (G06.26+)

User-Level Native Thread Primitives (GThread Library) 03/31/2005
Hewlett-Packard Company--540065-001 Page 3 of 46
1. Introduction
1.1. Overview
The GThread library is a NonStop operating system facility that provides primitives supporting user-level
multithreading on TNS/R and TNS/E systems. It is not a comprehensive threading package, but rather
provides the primitives to save and restore thread context, and to create the context for new threads.
GThreads replaces the direct manipulation of TNS registers typically used in threads packages for TNS
Guardian systems, allowing package conversions to native mode with minimal source changes.
This document covers GThread external functionality in its entirety. Existing TNS or TNS/R GThread
clients are not required to make any changes. This document introduces new interfaces which will
require modifications to client code in the TNS/E environment.
To promote an early migration to the new interfaces, and provide a consistent interface to GThread
clients designed to run on both TNS/R and TNS/E platforms, the new interfaces are also available on
TNS/R. The client externals are the same on both platforms, but the internal implementation differs.
Clients running on TNS/R are given the option
of using the new interfaces for two purposes:
1) Migration provides a single set of interfaces that work on both TNS/R and TNS/E.
2) Clients who do NOT intend to migrate to the new interfaces early are not required to convert.
1.2. Background and Definitions
The GThread library permits a client to implement user level "multithreading". Multithreading is defined
as the use of multiple "threads" within a single "process." Abstractly, a "process" is a set of resources for
running a program; it is primarily a set of memory resources and control structures. A "thread" is a set of
resources for the shared use of a processor; it includes a set of processor state (registers) and a stack on
which to activate procedures. In some operating systems, "process" (or "task") and "thread" are distinct
concepts; the simplest execution of a program requires one of each. More commonly, however, a process
includes one thread; this is the case with the NonStop operating system in both the Guardian and OSS
application programming interfaces (APIs). Thus a process is operationally defined as the entity created
by PROCESS_LAUNCH_, PROCESS_ SPAWN_, fork or one of their alternatives. It has both memory
resources and execution state, including the necessary stacks.
A multithreaded process has more than one execution thread. Each thread retains its processor state and
the history and local state of the procedures that have been entered in that thread and not yet exited. This
definition deliberately excludes mechanisms that do not retain procedure activation history for each
thread; while "state machines" and other mechanisms may enable one process to serve many clients and
interleave processing of their requests, they do not have "threads" in the sense of this document.
Each thread requires its own stack area in which to keep procedure activation records (stack frames).
Classically, there is one stack for each thread. However, for the Itanium® processor architecture in
TNS/E systems, each execution context has a pair of stacks. Within this document, the word “stack”
often refers to aggregate stack resources without regard to whether one or two stacks are involved. When
necessary, the two stack components are distinguished.