page_title: OS 2200
section_title: CPU dispatch
hierarchical_section_title: OS 2200 / History / The Exec / Performing work / CPU dispatch
caption_attribution_description: English: Unisys OS 2200 dispatching priority diagram for use in article.
context_page_description: OS 2200 is the operating system for the Unisys ClearPath Dorado family of mainframe systems. The operating system kernel of OS 2200 is a lineal descendant of Exec 8 for the UNIVAC 1108.
  Documentation and other information on current and past Unisys systems can be found on the Unisys public support website.
  See Unisys 2200 Series system architecture for a description of the machine architecture and its relationship to the OS 2200 operating system.
context_section_description: Once a run has been started, getting access to the processor controls its rate of progress.  The heart of the Exec is the Dispatcher which manages all the processors.
  The Exec supports up to 4095 dispatching priorities although most sites define only a small subset of those.  The two highest "priorities" aren’t switchable.  They are recognition of certain types of processing that must be allowed to continue on the processor on which they started until they voluntarily give up control.  Interrupt lockout occurs when an interrupt arrives or in a few special cases when other Exec code prevents all interrupts (in order to change some data that an interrupt handler may also access).
  Interlock is used by interrupt post processing routines that either need to run on the same physical processor or simply should not be interrupted.  The Dispatcher, I/O completions, and I/O initiation are some examples.  All locks used by both of these priorities are spin locks as the only way they can be set by someone else is on another processor and the design requires that they only be set for very short instruction sequences.
  High Exec priority is used by the operator command handler and some other functions that may have to run even when a real time program has control.  They are expected to use only very short amounts of time.  If they need more time, they should queue the work to be processed by a Low Exec activity.
  Real time activities have an unlimited processor quantum and run without switching unless interrupted by a higher priority real time activity or High Exec activity.  Real Time activities are given control of any available processor that is running something of lower priority.  Interrupts are sent between processors when necessary to ensure immediate availability.  Real time is used by customers to fly missiles, run simulators, and other functions that require immediate response.
  Transaction priorities may be handled in two ways as defined by the site.  They may be a sort of lower priority real time in that only the priority matters and the quantum size is essentially infinite.  This is appropriate for very short-lived transactions such as airline reservations; if one loops due to a programming error, the Exec will terminate it when it reaches its very small configured maximum time. The other form allows the Exec to vary the priority within a range to optimize system resource usage.  The approach gives higher priority and shorter time slices to programs that are I/O limited and progressively lower priorities but longer time slices to those that are computing.  The Exec dynamically adjusts these priorities based on behavior as programs often behave both ways at different times.  This approach is appropriate for longer running transactions like database queries or airline fare quotes.
  Batch and demand always use dynamically adjusted priorities.  Programs that are I/O limited or are in a conversation with a time-sharing user get higher priorities but short time slices.  More compute-oriented programs get lower priorities and longer time slices.
  The Exec has two additional mechanisms for optimizing dispatching.  One is affinity-based dispatching.  When possible the Exec will run an activity on the same processor that it was on the last time to get the greatest advantage of residual cache contents.  If that isn't possible it tries to keep the activity on the "nearest" processor from the standpoint of cache and memory access times.  The second is a "fairness" policy mechanism.  The site can define the relative percentage of resources to be allocated to each of transactions, demand and batch.  Within transactions and batch there are priority groupings that can further indicate what percentage of their group's time is to be allocated to the priority.  This ensures that  transactions cannot so dominate the system that no batch work gets done.  Within the various priority groupings it ensures that some progress can be assured for each group (unless the group percentage is zero).  These "fairness" algorithms only come into play when the pr
caption: Dispatching priorities diagram
exif: {}