Secretary

Intent

This pattern provides a simple way to manage one or more contexts. In current computer graphics and multimedia it has become a common convention to store and use more than one context - or environment of execution.  This pattern should provide a simple and understandable interface to switching, editing, sharing, destroying and creating contexts.

Also Known As

Context Manager 

Motivation

A secretary is an excellent example of the problem that needs solving with this pattern.  While working a secretary often has to complete multiple tasks concurrently.  To complete his tasks the secretary must have a workspace set-up to facillitate each task.  These workspaces might be files, a computer with a spreadsheet, a typewriter with company letterhead loaded, or a set of letter boxes with labels indicating IN/OUT/Pending/etc.  Occasionally the secretary will need to use pieces of two or more of these workspaces to finish a task. The secretary is also often asked to add a new task, and hence a new workspace.  Through his day he must work on each task, facing the workspace in his office chair to do so. As a task is completed, the workspace can be dissasembled and put away.  If the secretary had to put away the workspace every time that they switched to another task, they would spend their whole day setting up and taking down their worspace (stop stapling, put the stapler away, put the collated papers into a stack on the desk - take the stapler out, re-colate papers, start stapling).  The preservation of context or workspace is key to this pattern.  It is also imperative that the secretary knows where each workspace (context) is, if he couldn't find the papers to staple and stapler he couldn't staple them.

Applicability

This pattern can be applied in many places including thread management and graphics context management. You can recognize when this pattern is applicable by the desire to have independent environments or collections of variables and the ability to manage them.

Structure

Secretary Diagram

Consequences

  1. Overhead of context swap. Swapping your context has obvious performance overheads associated with your specific architecture. 
  2. Serious Performance issues. Done correctly this pattern can greatly enhance your performance, however if implementation is sloppy performance will suffer greatly.

Implementation

  1. Don't switch contexts unnecisarrily. Frequent context switching has obvious overhead, instead try making part of the context you need access to accessable from the other context. 

Sample Code and Usage

A secretary should be easy to use.  What follows is an example of what a secretary use might look like.  int my_context1 = make_new_context(); int my_context2 = make_new_context(); set_current_context(my_context1); // do some computation set_current_context(my_context2); // do some computation int my_context3 = make_new_context(shared_memory_from_context1); set_current_context(my_context3); // do some computation potentially using or modifying memory from context1 delete_context(my_context2);

Known Uses

OS multithreading, OpenGL rendering contexts, user level threads 

Related Patterns

Memento is closely related to this pattern.  There are some notable differences however.  Memento only allows you to take a snapshot of an object and return that same object the snapshot state.  Secretary allows you to copy the snapshot to a new object, create objects, share pieces of objects, and destroy objects.  Consider using this patter with proxy or another multi-user privelages pattern to allow special privelage contexts (ie, OS level permissions, controlling thread permissions, etc). 
Christopher E. Davis (chris2d@cs.unm.edu). Last updated on  12/01/2002