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 38 of 44
Main thread as an unthreaded context. However, a static thread could dispatch another static thread
directly, and any other thread can dispatch the Main thread.
3.5. Checkpointing
In “passive” checkpointing, the backup process duplicates exactly the memory image of the primary.
Passive checkpointing of threads is very difficult, and is not known to occur among GThread clients.
Passive checkpointing in users of the standard C/C++ libraries is not supported because of difficulty
duplicating the heap.
In contemporary applications, it is common to achieve fault tolerance by relegating that responsibility to
middleware such as TMF and Tuxedo, which frees the application code from concern with the details of
process-pair paradigms. Therefore, there is no support for passive checkpointing of GThread control
blocks and thread stacks.
In “active” checkpointing, the primary process explicitly sends messages to the backup containing data
that must be known to both. Typical active checkpointing paradigms send records representing
transactions or updates; they do not transfer procedure activation records (stack frames), so threads
introduce no distinct issues.
In TNS or native TNS/R clients of GThread, it is possible in principle to checkpoint the current activation
records of inactive threads. However, application of such data in the backup process would require
corresponding threads to occur at exactly the same addresses. No instance of such a paradigm is known.
The TNS/E interfaces do not accommodate such an approach.
3.6. TNS/E Usage Changes
Specific changes for TNS/E are described in the following sections.
3.6.1. Thread Setup and Initialization
The client is responsible for the allocation of the ‘stack space’ associated with the thread’s runtime stacks.
The allocated buffer is either used directly as a static stack (static threading), or as a save area for stack
contents (swapped threading). The client is also responsible for specifying the exact stack space size in
bytes. This responsibility carries with it an implied assumption that the client has knowledge (either
analytically or empirically) of stack space consumption for that thread in the runtime environment of the
host platform. This issue is further complicated for client code ported between host platforms where the
runtime environment can differ (i.e. TNS/R vs. TNS/E).
In order to alleviate this problem for typical clients, the GThread library provides the following interface
to return an estimated appropriate stack size for the TNS/E native platform given a size for the TNS/R
native platform:
GTH_GET_ESTIMATED_STACK_SIZE_( int32 sizeEstimate )
The sizeEstimate provided by the client is its ‘best guess’ at an appropriate stack space size in bytes for
the TNS/R native system. GTH_GET_ESTIMATED_STACK_SIZE_ returns an estimated size (if
needed) based on the host platform.
The GTH_GET_ESTIMATED_STACK_SIZE_ interface attempts to allow existing TNS/R native clients
to leverage the stack size calculations performed on that platform in order to quickly derive a stack size