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 5 of 46
|...
In the master protocol, the swap origin must occur beyond the stack frames of those unthreaded
procedures that remain on the stack while a thread is running. These frames are marked * in the diagram
and may or may not remain while the unthreaded master code is running.
Diagram 2
|--- stack root ---|--- unthreaded master ---|
|- * -|--- thread 1 ---|
|- * -|--- thread 2 ---------|
|- * -|...
1.4. User Thread Support
The NonStop operating system provides user-level thread support for TNS processes; both TNS and
native thread primitives are available, with essentially the same source-level API. The TNS threads serve
these two purposes:
Migration: An existing TNS program or thread library can be converted to use the new
primitives and tested in the TNS environment. This allows thread and native-
conversion issues to be separated.
Coexistence: The same source code (application or thread library) can be compiled for both
TNS and native use.
The GThread library does not provide kernel threads or preemptive thread scheduling.
1.5. Changes for TNS/E
The TNS/E architecture introduces changes to register size and format and a runtime environment
consisting of two active stack components: a memory-backed register stack, called reg stack, and the
traditional memory stack, called mem stack. (The reg stack is formally a memory backing store for a
hardware register stack; it is often called the RSE stack because it serves the processor’s Register Stack
Engine.) All of these changes affect the internal implementation of the GThread library for native clients
on TNS/E platforms. Register size and format changes do not affect the external interface exported by the
GThread library. However, the two-stack runtime environment does affect the external interface, due to
the previously externalized concept of a single
active physical stack for the runtime environment.
Changes are therefore necessary to the TNS/E GThread external interface in order to deal with the
TNS/E two-stack environment.
As these changes to the external interface are unavoidable, the interface design attempts to ‘abstract’ the
concept of physical stacks into a more general model of a single ‘virtual stack’ that the client references
via GThread interfaces. The GThread design includes managing the two TNS/E stack components so that
they occupy the single virtual stack space exported to clients. The virtual stack translations are performed
internal to the GThread library and are transparent to the user.
The changes affect native clients of the GThread library on TNS/E. The GThread implementation for
TNS clients does not change for the TNS/E platform. TNS clients have the option of using the new