User-Level Native Thread Primitives (GThread) Library White Paper (G06.27+, H06.03+, J06.03+)

User-Level Native Thread Primitives (GThread Library) 02/15/2012
540065-004 Page 5 of 44
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
the following 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
interface or continuing to use the original interfaces. Existing TNS clients using the GThread library on
TNS/E can avoid recompilation if they choose.
For TNS/E platforms, the following additions were made to existing interfaces:
1) A set of routines that replace directly accessing the thread control block. These routines abstract the
knowledge of the TNS/E stack architecture such that the client can see one virtual ‘stack’ per thread.
2) A routine that returns an estimated stack size based on the client’s stack size allocation on TNS/R.
The results of this optional routine are used for stack allocation and thread creation.
3) New routines to assist in the stack saving process for swapped stack threads.
4) A define and further enhancement of the GTHREAD_INITIATE_call that permits clients to control
stack allocations on TNS/E platforms.
1.6. Changes to Support Protected User Stacks
As of the H06.21 and J06.10 Release Version Updates, the GThread library supports protected user
stacks, in addition to the previously-supported unprotected user stacks. To take advantage of this support,
clients must allocate and deallocate protected user stacks through the STACK_ALLOCATE_() and
STACK_DEALLOCATE_() Guardian procedure calls, respectively. These functions are documented in
the Guardian Procedure Calls Reference Manual. Additionally, a new Swaptions parameter must be