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 41 of 44
• Use protected stacks allocated with STACK_ALLOCATE_()
• Use the 32-bit heap, such as by calling malloc32()
• Allocate stacks within one or more 32-bit segments created by the program. For
example, use memory allocated through SEGMENT_ALLOCATE_() or shmget () or shmat
().
3.6.3. Thread Switching (Context Manipulation)
This section is specifically about migration of GThread clients from the original interface implemented on
TNS/R to the revised interface on TNS/E. The revised interface is available on both platforms.
Changes to thread switching are divided into two types; changes associated with switching swapped
threads, and changes associated with switching static threads.
3.6.3.1. Changes Associated with Swapped Threads
For swapped threads, the TNS or TNS/R native clients of the original interface must perform the
four following steps to switch threads:
1) Capture the context for the current thread (GTHREAD_SETJMP_).
2) Copy the contents of the runtime stack(s) for the current thread must its save area (explicitly
done by the client using pointers and sizes obtained directly from the thread control block).
This step may also include dynamic resizing of the save area if the client code is designed to
handle overflow of that area.
3) Copy the contents of the save area for the target thread to the runtime stack(s) (explicitly
done by the client using pointers and sizes obtained directly from the thread control block).
This step can only be done after some GTHREAD ‘thread switching preparation’ is
performed (the step must be preceded by a call to GTHREAD_SWAPIN_SETUP_).
4) Switch control to the target thread (GTHREAD_LONGJMP_).
The changes introduced by the TNS/E platform do not affect the externals of
GTHREAD_SETJMP_ or GTHREAD_LONGJMP_, so client code to implement steps 1 and 4 is
unaffected.
Steps 2 and 3, however, where the client saves and restores runtime stack information, require
client changes for TNS/E.
On TNS/R, the client must access elements in the thread control block directly in order to
perform the stack copying. These elements implied a runtime architecture consisting of a single
stack. TNS/E architecture introduces the concept of a runtime environment consisting of two
stacks, so client code would minimally need to change to take the two stack architecture into
account. The client code could be further complicated if it needed to execute on both TNS/R and
TNS/E platforms.
Four interfaces are exported to hide the various platform stack implementations and present the
client with the concept of a single ‘logical stack’ that needs saving on context switches.