The operating system, as well as some real-time applications use interrupts to ensure that external events are noticed by the operating system in a timely fashion. It is critical that interrupts be handled promptly and according to their relative priority.

Within Windows 2000, the kernel and the hardware abstraction layer (HAL) are tuned to optimize interrupt delivery and event dispatching. The kernel provides interrupt dispatching to the rest of the system. The kernel can operate at one of 32 possible interrupt levels, as shown in the table below. These levels help prioritize the tasks that must be accomplished before other, less time-critical work. The kernel reserves eight interrupt levels for its own use. The remaining 24 interrupt levels are mapped onto hardware interrupts with the HAL.

Windows 2000 handles interrupts on a preemptive basis. When an interrupt occurs, all execution at lower interrupt levels is suspended and execution begins immediately on the highest-level request. Processing continues until the highest-level process has been completed. This places a responsibility on device drivers in that system responsiveness is directly related to how quickly a device driver exits its interrupt routine. 

All execution by the processor at an interrupt level is at a higher priority that all priority levels associated with a process thread.  The allowed process thread priorities are described below.

A process within a Windows 2000 system is an independently executing instance of an application/program.  A process comprises an address space (generally separate from all other process), object handles, and one or more paths of execution (threads).  Microsoft Word, Notepad, and Internet explorer are examples of familiar processes within a Windows 2000 system.  A process is created by the O/S using an program executable image stored on the disk as a “.exe” file.  One or more instances of a disk based program may be started and executing at any time, and each becomes an ‘instance’ of the program, and an independent process.

A thread is an independent execution path within a process.  Each process has at least one thread, the primary thread.  When a process begins, the O/S begins the process by executing this primary thread. 

Additional threads may be started by the process.  These threads operate as part of the process and within the virtual space of the process.  However, these threads are scheduled for execution independently from the execution of the primary thread.  This might be done by the process to handle additional work items such as maintenance / background functions, or additional work items.  Each thread may operate completely independently from the other threads within the process (as far as CPU utilization is concerned).  Often, in a standard windows process, user interface thread(s) are used to handle user input and output, while worker threads are used to handle tasks requested by (or done on behalf of) the user requests.

The standard Windows 2000 system supports 32 priority levels for scheduling threads within a process.  These priorities are numbered 0 through 31, with priority 0 being the lowest and 31 being the highest priority.  The Windows 2000 scheduler is a pre-emptive scheduler; it will attempt to execute the thread with the highest priority at any instant in time.  Whenever the dispatcher reschedules a processor, it will find the highest priority thread available (and able to use a processor resource) and assigns the processor to execute that thread.

Windows divides the 32 priority levels into two (2) groups or ‘classes’.  When a process is started in standard Windows 2000 system, it will be started as either a ‘Normal’ or a ‘Real-Time’ process.  Once the process is started as Normal (sometimes called the Dynamic or Variable-Priority) or Real-Time, all of the threads in that process will have priorities reserved for that type of process. 

The priority of a thread of a ‘Normal’ process ranges from priority levels 1 through 15.  The ‘Real-Time’ priority range includes priority levels 16 through 31.   Thus, all threads within a ‘Real-Time’ process are scheduled for execution before any of the ‘Normal’ threads.

Typically, real-time processes will run at priority 24. Other applications (dynamic classes) have a base priority class of 15, 13, 9 (normal foreground process), 7, 4, 1, and 0.

A process is assigned a ‘base priority’.  Each thread has a current priority derived from the process' priority class.  By using an application programming interface (API) call that varies up or down from the process' base priority, you can vary the current priority up or down within defined limits. For example, a process running at real-time class 24 can have threads that run anywhere between classes 26-22, depending on their own independent priority. However, these threads will always stay within the real-time priority class.

The 5 priorities clustered around Base Priority (BasePriority-2 through Base Priority+2) are used to assign a specific priority to a thread.  (These are often termed: Lowest, BelowNormal, Normal, AboveNormal, and Highest). 

The Windows O/S scheduler will adjust the priorities of threads within the ‘Normal’ (or Variable-Priority) class in an attempt to optimize system response time. CPU bound threads will tend to have their priorities reduced while threads ending a wait (for a resource, time interval,…) will have their priority raised.

Threads are independently scheduled by the executive. Associated with the process is a quantum (the maximum amount of time a thread can execute before the system checks to see if other threads with the same priority want to execute). In general, real-time processes will have priority over almost all other activities or system events. However, for processes in the spectrum of dynamic classes that are running at lower priority levels, a number of events within the system, such as I/O completion, could cause a temporary priority boost for a thread, giving it priority within a process.

With the installation and use of the VenturCom Real-Time extensions:

• Real-Time Execution (RTX) functionality is added to the Win32 environment, and

• an RTSS environment is added to the standard Win32 environment.

Some objects are valid only in the environment in which they were created (Ex: thread, timers, interrupts). Other objects (semaphores, events, mutex objects, and shared memory) may be used to synchronize and communicate between RTSS and Win32 processes and threads.

RTSS Environment

An RTSS thread is a unit of execution in the RTSS environment.  A ready-to-run RTSS thread is scheduled before all Windows 2000 threads.  Unlike a Win32 thread, which may have the processor removed by the O/S, an RTSS thread runs until it gives up the CPU. A thread gives up the CPU when it:

• Waits for a synchronization object

• Lowers its own priority or raises another thread’s priority

• Suspends itself

• Returns from the timer or interrupt handler (applicable to timer and interrupt threads) routines

• Calls Sleep with an argument of 0
  
  

The RTSS environment has no distinct priority classes, so the threads of all RTSS processes compete for CPU using the thread priority only. An RTSS thread runs at one of 128 distinct priority levels. Threads execute in priority order and in “first in, first out” order within any single priority. Threads are not subject to time-sliced sharing of a processor; that is, an executing thread runs until it gives up the CPU, or until an external event readies a higher priority thread. RTSS scheduling uses a priority promotion protocol to eliminate unbounded priority inversion.

Win32 Environment

A Win32 RTX program starts execution in the real-time priority class. RTX provides a mapping between RTSS and Win32 subsystem priorities. However, Win32 scheduling may exhibit unbounded priority inversion.

Programming Considerations

All processing in the RTSS environment takes priority over all processing in the Win32 environment.

VenturCom RTSS vs. Win32 Priority Spectrum

Open

RTSS Priorities in the Win32 Environment

The following table, RTSS to Win32 Thread Priority Mapping, shows how RTSS symbolic priority names translate to and from requests for a particular Windows 2000 priority when RtSetThreadPriority is called by a Win32 program.

Process control systems often have the need to support multiple sessions from remote locations for program development, support, and maintenance.  Historically this has been accomplished using an asynchronous communications connection or a Telnet server on the process control system and initiating standard terminal or Telnet sessions from a client on a PC based workstation.

Although Windows 2000 systems are often considered single user systems, there are a number of attractive and easily managed alternatives for supporting system access with simultaneous sessions when Windows 2000 is configured as a process control system host.  These include:

• FTP access to files

• Sharing Drives and Directories

• pcAnywhere console sharing and remote access

• Terminal Services

An FTP server is configured on each process control system.  With proper configuration some or all of the files resident on the system may be made accessible via FTP.  For the Tsentry systems, read and write access is provided to all source, program development, and process data files for users with satisfactory security credentials.  Access to these areas is strictly controlled and implemented with the use of standard NT User ID and Password security.