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 44 of 46
where cb is the thread control block of the current thread whose context is being saved or
restored. GTH_STACK_SAVE_ copies stack frames into the save area.
GTH_STACK_RESTORE_ restores stack frames from the save area.
The following interfaces are used to access the information needed as part of detecting a
potential overflow of the save area if the copy was performed (and allowing for dynamic resizing
of the area):
GTH_STACK_USED_( GThread_CB cb )
GTH_ALLOCATED_SIZE_( GThread_CB cb )
GTH_STACK_USED_ returns the total stack area used in bytes. GTH_ALLOCATED_SIZE_
returns the size of the swap space allocated.
For those clients that provide the capability of dynamically resizing the stack save area in the
event of overflow detection, the following interfaces are provided:
GTH_ALLOCATED_BASE_( GThread_CB cb )
GTH_ALLOCATED_SIZE_( GThread_CB cb )
GTH_SET_ALLOCATION_( GThread_CB cb, void * saveArea, int32 size )
For swapped threads, GTH_ALLOCATED_BASE_ and GTH_ALLOCATED_SIZE_,
respectively, report the base address and length of the save area; GTH_SET_ALLOCATION_
sets those values. See the “Suspend current thread” discussion in Section 3.2 for example
pseudo-code illustrating the use of these and other interfaces.
3.6.3.2. Changes Associated with Static Threads
For static threads, context switching is simpler since there is no stack copying. The client
performs the following two steps to switch threads:
1) The context for the current thread must be captured and saved (GTHREAD_SETJMP_).
2) Control is switched to the target thread (GTHREAD_LONGJMP_).
Since no stack copying is performed, the problems addressed in Section 3.6.3.1 on swapped
threads are not applicable to static threads. However, a problem unique to static threads is stack
overflow detection. In the case of static threads, however, overflow is considered a fatal error.
Based on the design of static threading where the client is responsible for allocation of memory
used for stacks, it is not easy to guarantee that all stack overflows are detected in a timely
manner. Typically, clients take one of three approaches for detecting stack overflows:
1) Clients add a ‘guard area’ at the end of the stack containing a data pattern. The guard
area is validated prior to switching thread contexts; overwriting of the guard area,
indicates a stack overflow has occurred. This approach suffers from a dichotomy: if the
guard area is too short, it can be skipped over (native stack frames often contain “gaps”
in which nothing is stored), but a longer guard area requires more time to validate.
Furthermore, while the TNS/R architecture involves a single memory stack growing