Ravenbrook / Projects / Memory Pool System / Master Product Sources / Design Documents

Memory Pool System Project


                  THE DESIGN OF THE MPS THREAD MANAGER
                       design.mps.thread-manager
                           incomplete design
                           richard 1995-11-20

PURPOSE

The Thread Manager handles various thread-related functions required by the 
MPS.  These are:

  - stack scanning

  - suspension and resumption of the mutator threads

CONTEXT

The barrier requires suspension and resumption of threads in order to ensure 
that the collector has exclusive access to part of memory.  
[design.mps.barrier.@@@]

Stack scanning is provided as a service to the client.  [Link?@@@]

OVERVIEW

Each thread is represented by an object of type "Thread".  The Thread type is 
implemented as an ADT.  A deque of Thread objects is maintained in the Space.  
The Thread object contains OS dependent information about the thread -- 
information necessary for manipulating the thread and for scanning the thread 
context.  Thread "registration" adds or removes the current thread to the 
Thread deque in the Space.

DETAILED DESIGN

Stack Scan
This is a module providing a stack scanning function.  The scanning is arch/os 
dependent.  Typically the function will push the save registers (those 
preserved across function calls) which plausibly contain pointers (not FP/debug 
registers) and call TraceScanStack on the appropriate range.

Thread Interface

- Register/Deregister
  register returns "Thread"

- Suspend/Resume
  suspends registered threads which are not the current thread

- ThreadDequeScan
  ambiguously scans the stacks and root registers of all threads.  The exact 
definition is os/arch dependent

Single-Threaded Generic Implementation

- single thread
- Suspend/Resume do nothing because there are no other threads.
- registration records stack base only.
- ThreadDequeScan calls StackScan

Win32 Implementation
- supports multiple threads
- structured exception style faults are expected
- suspend/resume loop over threads and call Win32 suspend/resume
- registration records information for current thread
  - stack base for current thread
  - Win32 "handle" with SUSPEND/RESUME and GET CONTEXT access to the thread.  
This handle is needed as parameter to
    - Suspend/ResumeThread
    - ThreadGetContext
  - Win32 ThreadId this is so that the current thread may be identified.
- stack scanning is Win32 specific
  - ThreadDequeScan uses GetThreadContext for other threads, giving root 
registers and the stack pointer
  - The thread's registers are dumped into the CONTEXT structure and fixed in 
memory.
  - scan the stack (getting sp from CONTEXT)
  - ThreadDequeScan calls StackScan to do the current thread.  The current 
thread is different because GetContext doesn't work on it.   (The context would 
not necessarily have the values which were in the saved registers on entry to 
the MM).

ISSUES

Scanning after Exceptions
StackScan relies on the non-preserved registers having been pushed on the 
stack.  If we want to scan after a fault we must make sure that these registers 
are either already stored on the stack, or, have an extra function to do this 
explicitly.

Multiple Registration
It is not clear whether a thread should be allowed to be registered multiple 
times.  We do not provide a mechanism for knowing whether a thread is already 
registered with a space.

A. References

B. Document History

2002-06-21 RB Converted from MMInfo database design document.