Context Switching
Depending on the semantics and execution model being implemented by the environment manager, it may be necessary for the manager to get control as CMS switches among threads. CMS provides for this by allowing RTEPCR to specify the address of an exit that should be driven when context switching operations occur. To provide for additional flexibility, CMS allows the context switch exit to be different for each process.
Context switching is a four-part operation as follows:
- The execution state of the currently-executing thread is saved. The currently-executing thread is also called the old thread.
- A thread is selected for execution. The chosen thread is called the new thread.
- The execution state of the new thread is restored.
- Control is passed to the new thread.
These steps are always the same, regardless of the processes and dispatch classes to which the old and new threads belong.
- Word 0
- X'0000' (indicates save operation)
- Word 1
- Address of environment manager anchor word for the process owning the old thread
- Word 2
- Address of environment manager anchor word for the old thread.
- Word 0
- X'0001' (indicates restore operation)
- Word 1
- Address of environment manager anchor word for the process owning the new thread
- Word 2
- Address of environment manager anchor word for the new thread.
For a given thread, the context switch exit (RESTORE function) is the first exit to be driven. In particular, it is driven before RTETCR. The first time the context switch exit is driven for a given thread, the environment manager's thread-specific anchor word will be zero. This gives the context switch exit a way to know whether RTETCR has been driven yet for the thread.
Together these two exits allow the environment manager to perform environment-switching operations in concert with CMS's execution switching operations.
The context switch exit must not call the multitasking API and it must be MP-capable.