Software for the analytical laboratory is just becoming available to take advantage of this new desktop PC computing mode. In this article, we explore the concepts and implications of multitasking for PCs in the laboratory and relate how such programs work when implemented in current multitasking operating systems. We also describe example applications in data presentation, analysis, and acquisition. Multitasking operating systems
Multitasking in Laboratory Personal Computers Richard B. Lam, James W. Cooper, Scott Thieret, JeanChristophe Simon, and Edward P. Clarke, Jr. Laboratory Automation Group IBM T. J. Watson Research Center P.O. Box 218 Yorktown Heights, NY 10598
History has a cyclical nature, and computing systems history is no exception. From their initial introduction, traditional mainframe computers quickly
evolved to serve multiple users. Jobs run in batch mode, and eventually as interactive sessions, appeared to the users to be run simultaneously. This time-sharing mode of operation is standard for mainframe and minicomputer systems today. Evolution of the personal computer (PC), originally conceived for the single user and for relatively simple computing tasks, has also followed this path. PC capabilities have inevitably grown toward making the desktop computer a viable multitasking platform.
30 A • ANALYTICAL CHEMISTRY, VOL. 63, NO. 1, JANUARY 1, 1991
Multitasking can include task switching, multiprocessing, coprocessing, distributed processing, and parallel processing. In this article, multitasking refers to running multiple concurrent programs or multiple copies of a program on a single PC. The distribution of tasks among many computers in a network (distributed processing) and the various ways of using multiply connected central processing units (CPUs) to carry out tasks (parallel processing) are not discussed. Coprocessing, in which a single CPU controls the bulk of the task and portions of the code are executed by a math chip or coexisting CPU within the same PC, will be discussed. Multitasking does not mean that a single CPU is running many programs simultaneously. PCs typically have a single instruction stream and thus can handle only one task at a time. The apparent simultaneous execution of several programs is handled by a process known as time slicing or context switching. As illustrated in Figure 1, a CPU executes one or more computer instructions (such as MOV or PUSH) in one program until it receives a signal to switch to another task (or context). This signal triggers the system to save the current state of the executing program, including all CPU flags, registers, and memory states, and begin executing another program. When another signal is received, the system saves the information about the second process and restores the state of the machine to begin executing where it left off in the first process. For two completely compute-bound programs (i.e., computing continuously rather than waiting for an input), this method of sharing computer resources is not productive because one CPU still runs all of the instructions of each process. No time is saved because the CPU would take the same amount of time to run both processes sequentially. In fact, the overhead involved in switching between the tasks will consume some CPU time, so the time to multitask the two processes will probably be greater. However, many programs spend most of their time in a loop, waiting for input from the keyboard, mouse, or serial port. This dead time, sometimes 0003-2700/91 /0363-030A/$02.50/0 © 1990 American Chemical Society
referred to as a "spin loop," is a waste of CPU cycles unless the extra CPU time is used to handle other processes. The effective use of the CPU is handled by a system task known as the scheduler or dispatcher. A scheduler can use two main strategies for control when the CPU switches to an alternate task: cooperative and preemptive multitasking. In cooperative multitasking, the scheduler must wait for a program to relinquish control to the system. Another program is then selected to run while the previously running program waits for its next turn. Applications written for this type of system must be "multitasking aware" and give up control at certain points in the program. Microsoft Windows and the MultiFinder system on the Apple Macintosh both use cooperative multitasking. Because all programs must be written to cooperate in relinquishing time, this method is not strictly suitable for data acquisition where timing may be important. By contrast, preemptive multitasking is controlled by the system in conjunction with a timer or other low-level interrupt. The system scheduler simply takes control with each interrupt and switches tasks without notifying any processes. Time slices are provided on a priority basis, and individual applications have little control over how the system assigns CPU time. Thus it is difficult, but not impossible, to construct real-time applications. The most common preemptive operating systems for PCs today are OS/2 and UNIX. Other proprietary versions of UNIX include QNX and Apple's AUX. Processes and threads. With OS/2 and UNIX you can start multiple applications by using the operating system command line interface or by selecting programs from a menu. In addition, it is possible for applications to start "child processes" under both operating sytems. Child processes are completely separate programs that manage their own resources such as files and memory. For example, a child process might be started to plot a spectrum on some hardcopy device, thus freeing the parent process for other acquisition or analysis tasks. These child processes are also referred to as background tasks, with the parent or currently active process running in the foreground. Multitasking systems do not intrinsically require a graphical user interface (GUI) such as Windows, OS/2 Presentation Manager, X Windows, or Motif for UNIX. However, most modern operating systems offer some variant of the "point-and-shoot" interface with drop-down or pop-up menus, dialog boxes with push buttons, and list and check boxes. For these graphical screens, the operating system allocates
a session, consisting of either a full screen or a window, for each application. Such windows provide convenient visual interfaces for organizing and tracking the status of running applications. Applications may, however, make use of multiple windows without having each window correspond to a child process. A multiple process example. To illustrate how child processes can be used in the laboratory, consider a pharmaceutical analysis laboratory where a series of samples must be run through an automated analysis procedure. The sample handling, extraction, and analysis procedure generates sample weight and LC data, which must be integrated
these operations is computationally intensive, each could be carried out on a single multitasking computer. Threads. Under OS/2, a simpler type of multitasking is available using "threads," or sections of a single program that are started by and run asynchronously from the main process (1). Every application has one main thread: Other threads share the data and resources of the main thread. Threads therefore require less overhead than separate child processes and are as easy to implement as subroutines. A program can use threads whenever it needs to perform some activity that might take a long time to complete. For example, it might start a thread to load
A/C INTERFACE into a report for the scientist. A technician runs a program that starts a child process to control a robot to handle each sample. A second child process collects data from a balance, and a third logs data from a liquid chromatograph. Meanwhile, another application integrates the peak data, the results of which are linked via dynamic data exchange to a document in a word processing program. Procedures similar to this example are often carried out today using two to five conventional computers, each controlling one aspect of the analysis. However, because none of
a large file from disk, scale data for display, perform complex math calculations, or acquire data. In our hypothetical pharmaceutical analysis above, the application might use one thread for writing the balance and chromatographic data to a disk file. Another thread could scale the incoming chromatographic data and plot it to the screen. Still another thread could send the data to the report program. Synchronization and communication. Whenever multiple processes operate on the same or dependent data, problems occur in synchronizing these
Figure 1. Illustration of multitasking two processes. The number of instructions actually run within each time slice is proportional to the length of time allocated by the system to each process. ANALYTICAL CHEMISTRY, VOL. 63, NO. 1, JANUARY 1, 1991 • 31 A
A/C
INTERFACE
tasks. In our example, the process reading the balance must somehow communicate the data to the process or thread responsible for storing the data in a file. Similarly, the chromatography data acquisition code must pass the digitized detector signal to data logging and peak analysis routines. This may require synchronizing with the peak analysis routine so that peak areas are not computed until all the data are available. There are five techniques for such interprocess communication: semaphores, signals, messages, pipes, and shared memory. Semaphores are used to synchronize operations between processes or threads. Semaphores are simply global variables or special operating system structures that are set and cleared by the communicating processes. They allow processes to share common resources such as files or data without conflicts. For example, it would be foolish to change the value of a variable controlling the resolution of a spectrum while a spectral scan is in progress. Likewise, two processes should not actually control the spectrometer at the same time. Therefore, the acquisition routine sets a semaphore controlling access to the resolution variable until the acquisition is complete. The process trying to change the value waits for the semaphore to clear before continuing. To avoid the dreaded spin loop, which wastes computer time, operating systems provide calls that relinquish all of a thread's time slice until the semaphore clears. Signals are special inputs, triggered by keystrokes, mouse movement, button presses, or other user actions, that cause execution to transfer to a routine called a signal handler. Operating systems often have default signal handlers for signals such as floating point errors or control-break keystrokes. You can write other signal handlers to control situations such as interrupting an experiment or triggering an alarm. For example, stopping an automated analysis may require resetting a robot arm to a home position and closing any open files. Messages are function calls made by the operating system to procedures that manage the behavior of windows. Because many processes have a main window, these calls provide a way for windows to communicate. In a windowing system, the application program tells the operating system the location of these procedures, and the operating system makes function calls to these routines when the window needs to be updated. You can, however, pass messages to these windows through the operating system and even define mes-
• here are five techniques for such interprocess communication: semaphores, signals, messages, pipes, and shared
k
memory.
sages with private meanings for changing application-specific parameters. Pipes are used to pass streams of data between processes. The communicating thread opens a pipe for reading or writing by an operating system call. The read and write handles to a pipe are returned by the operating system and can be provided to child processes as their standard input or output device handles. Alternatively, named pipes enable separate programs to communicate by referring to a specific pipe name, analogous to a file name. Data are read from or written to pipes just as for files, with the added advantage that named pipes are bidirectional and can be used for reading and writing by both processes. When two processes need access to the same block of data, it may be advantageous to use shared memory. Shared memory allows two processes to read and write to the same memory locations if both of them have been granted access to that memory. In protected-mode operating systems you cannot, however, write to any memory to which you have not been given access. As with named pipes, named shared segments are analogous to file names. The process may obtain the segment name or selector value through a pipe or file. To prevent both processes from writing to the memory simultaneously, you control access to
shared memory using a semaphore. Figure 2 (p. 35 A) shows one way to design the pharmaceutical analysis application software from a process viewpoint. Several methods of interprocess communication are used—the thread controlling injection of a sample into the chromatograph uses a semaphore as a start signal for the LC data acquisition. Similarly, another thread informs the balance (when a sample is ready to be weighed) through a semaphore. The chromatographic data are displayed by a thread spun by the acquisition task. When the chromatogram is complete, the data are passed through a pipe to the analysis routine. The sample weights and peak areas are available to the analysis and report processes through shared memory. The analysis task also uses a thread to store the data automatically in a disk file. Access to devices in multitasking systems In a multitasking system connected to any device, it is quite possible that more than one program will attempt to access that device at the same time. Whether the device is a disk, a display, or an analog-to-digital converter card, this can have serious consequences if the access is not strictly controlled by the operating system. Thus, application programs may not make direct changes to device registers. Instead, the application makes calls to a single program that has control of the device, called a device driver. Although such drivers traditionally have been written in assembly language with great difficulty, modern compilers make it possible to write them in languages such as C (2). These device drivers control multiple access to the device either by allowing only one program to open the device at a time or by queuing requests until the device is free. OS/2 allows access to device registers using special program sections called IOPL Segments, but only a device driver can register and service interrupts from a device. Thus an application program can request access to device registers under slow data-rate conditions, but a device driver must be written if the device is to signal the computer using interrupts. Timing requirements in multitasking systems One of the principal problems inherent in multitasking systems is the amount of overhead introduced by time slicing and process scheduling. Because of this overhead, high-speed data acquisition may be problematic: A data point may be missed if the system cannot acknowledge an interrupt before another continued on p. 35 A
32 A • ANALYTICAL CHEMISTRY, VOL. 63, NO. 1, JANUARY 1, 1991
A/C
INTERFACE
one occurs. The interval between the time a de vice causes an interrupt and the time that the device's interrupt service rou
tine begins executing is called the in terrupt "latency." In operating sys tems such as OS/2 this latency is usual ly ~50 μβ (3). Thus, it might not seem
possible to do data acquisition at rates >20 kHz. In addition, if several devices are attached to the same interrupt lev el, then polling to find out which device
Figure 2. Sample process architecture for a pharmaceutical analysis application. Circles indicate processes or threads, solid boxes represent shared memory segments, and outlined boxes denote semaphores. A pipe is used to transfer the digital LC data between the acquisition and integration tasks. ANALYTICAL CHEMISTRY, VOL. 63, NO. 1, JANUARY 1, 1991 • 35 A
A/C
INTERFACE
caused the interrupt may further extend this latency. When data acquisition continues for more than a few milliseconds at a time, other interrupts probably also will occur. The most likely such interrupt is the time-slicing interrupt, which, under OS/2, occurs every 32 ms. If another process becomes active after such a time slice, your process could, in theory, miss a data point. Fortunately, if the device signals the computer with interrupts, your program will receive the data point whenever it occurs unless data points are coming far faster than the time-slicing interrupt. More serious than this, however, is the fact that many multitasking systems also support virtual memory, so any program can use more memory than the computer actually has available by swapping parts of memory to disk. If a program requests more memory than is currently free, memory must be swapped and moved and interrupts must be turned off for the duration of the swap, because the interrupt return location itself may be moved. Clearly, this could result in a severe data-handling problem. There are several possible solutions. If the data rates are slower than 20 kHz, interrupts will always be acknowledged in time; if the length of the acquisition is very short, the time-slicing interrupt will not interfere. If the acquisition time is longer, the priority of the process should be set higher than the time-slicing interrupt by selecting a low-numbered interrupt level in the PC—usually level 3. However, all of these potential problems are easily solved if the acquisition board supports direct memory access (DMA). These boards use a separate chip within the computer to transfer data along the bus from the board to the PC's memory without using the CPU at all. Such data transfers take place regardless of which process is running or which interrupt is occurring. We have found that DMA device drivers can run at the maximum speed of the board in multitasking systems. Finally, some more powerful acquisition cards allow you to acquire data into onboard memory at very high speeds. One such card (from QuaTech, Inc., Akron, OH) allows acquisition of up to 1 Mbyte of data at speeds up to 1MHz.
was designed to be a multiuser and a multitasking system. Thus each task may be associated with a separate user who will expect to get reasonable computer response. Because of this design, no particular task can get and keep the high priority needed for a real-time data acquisition program. The only way to solve this is by modifying the UNIX kernel to allow processes to adjust their priorities irrespective of the fairness algorithm.
One kernel that has these modifications is IBM's AIX 3.1, which runs on RS-6000 workstations. We have begun writing device drivers for the RS-6000 to understand the features of the system and to see how it can fill our laboratory's needs. Real-time UNIX systems can be used for instruments or experiments with moderate-to-high data acquisition needs and high computational requirements. The AIX 3.1 kernel allows the user to
Figure 3. Schematic of the PS/2 and Wizard Card configuration. The Intel Î386 and i860 processors and the PS/2 32-bit dynamic random access memory (DRAM) connected to the Micro Channel bus are shown. The image data are collected and displayed by the i386 using the system RAM. A 64K shared memory segment is mapped to the Wizard Card address space and used to transfer the data to the Wizard 64-bit DRAM, where the image is rendered. The new image data are transferred back through the 64K memory segment for subsequent display.
Data acquisition under UNIX UNIX presents special problems for data acquisition because the usual UNIX scheduler uses a "fairness" algorithm t h a t gives all tasks equal amounts of computer resources. This approach was adopted because UNIX
Figure 4. Disk magnetic readback signal data displayed as a series of lines, one for each successive track.
36 A • ANALYTICAL CHEMISTRY, VOL. 63, NO. 1, JANUARY 1, 1991
modify process priorities to be as high as necessary—even higher than the scheduler itself, so the scheduler cannot interrupt a high-priority acquisition task. We have found that this feature allows interrupt-driven data acquisition at rates as fast as 25 kHz. In fact, with the eight-word buffer present on the National Instruments MIO-16 card, we are able to avoid timing problems simply by reading all newly acquired data points each time an interrupt occurs. In addition, because this is a DMA-controlled card, it is not limited by the interrupt latency considerations if DMA is used instead. Application examples
At the IBM T. J. Watson Research Center, our scientific data acquisition, analysis, and presentation strategy is based on an internal tool called SciBench. This program is written specifically for multitasking environments, using either AIX (the IBM version of UNIX) and OSF/Motif or OS/2 Presentation Manager. This software runs on either PS/2 or RS-6000 computers, and a commercial OS/2 version is available. Some of the current SciBench applications and development work in progress are described below. Stepper motor control. One of the most common operations in our laboratory is the manipulation of samples as their surfaces are studied by various techniques. This is usually done by using a set of stepper motors to manipulate the position of the surface. Stepper motors are controlled by using either a General Purpose Interface Bus (GPIB) eight-bit parallel interface or a serial (RS-232C) interface. In both cases, the commands are simply sets of characters sent to the RS-232C port or the GPIB device driver provided by the manufacturer. One such GPIB interface card is available from National Instruments, Inc. (Austin, TX) with device drivers for both OS/2 and AIX. As stepper motor motions are fairly slow, there are no real data rate problems and the manipulation code can easily be written in C or, in the case of OS/2, also in compiled BASIC (4). In one current application, we use a controller connected to the serial port to control five stepper motors that move a sample in three dimensions while allowing two further angles of motion to an X-ray source for X-ray crystallographic measurements. Image rendering using the IBM Wizard Card. The IBM Wizard Card is a Micro Channel bus master card containing an Intel i860 microprocessor chip with eight megabytes of 64-bit onboard memory. Although this processor can be used as a very fast math
Figure 5. Data from Figure 4: (a) mapped into a circular array and (b) rendered in three dimensions on a PS/2 with an Intel i860 coprocessor. ANALYTICAL CHEMISTRY, VOL. 63, NO. 1, JANUARY 1, 1991 • 37 A
O'*ACC\lt\
+AW
Λ
