Databook for OS/2 – Chapter 2 – Inside OS/2 Warp
By David Both from Databook for OS/2
Overview
IBM’s newest version of Warp, code named Merlin, and officially called Warp 4, has many important new features. Among the more important and interesting of these are integrated voice recognition, a help feature called WarpGuide, and a usability feature called the Warp Center.Warp 4 retains its predecessor’s Crash Protection(TM) which prevents a crashed program from causing the entire system to crash. It also keeps its powerful multitasking capabilities and the ability to run all of your current DOS and Windows 3.1 applications.
The workings of some of the major features of OS/2 Warp are discussed in a fair amount of detail in Chapter 2. All versions of Warp covered here. Warp 3, Warp Connect, Warp 4, and Warp Server, all work in exactly the same way at this level because they share the same kernel.
The specific functions covered in this chapter are multitasking, the OS/2 ring protection mechanism, memory protection, and Crash Protection. What multitasking is and how it can benefit you is covered. How the priority-based, preemptive multitasking of OS/2 works and why it is important. Memory protection and the ring protection mechanism of the 80×86 and Pentium Processors and how OS/2 uses them to provide crash protection.
The OS/2 Kernel
The kernel of any operating system provides the core functions for that operating system. It is the part of the operating system that performs basic functions such as allocating hardware resources like memory and CPU time. The OS/2 kernel functions reside in the OS2KRNL executable file which is loaded during boot. Note that the file name has no extension.
The OS/2 kernel performs the following basic functions:
- Memory management. The kernel allocates and deallocates memory and assigns physical memory locations based upon requests, either implicit or explicit, from application programs. In cooperation with the CPU, the kernel also manages access to memory to ensure that programs only access those regions of memory which have been assigned to them. Part of memory management includes managing the SWAPPER.DAT file and the movement of memory pages between RAM and the swapper file on the hard drive.
- Task management. The OS/2 kernel manages the execution of all tasks running on the system. The scheduler portion of the kernel allocates CPU time to each running process based on its priority and whether it is capable of running. A task which is blocked – perhaps it is waiting for data to be delivered from the disk, or for input from the keyboard – does not receive CPU time. The OS/2 kernel will also preempt a lower priority task when a task with a higher priority becomes unblocked and capable of running.
- Interprocess communication.Interprocess communication (IPC) is vital to any multitasking operating system. Many tasks must be synchronized or communicate with each other to ensure that their work is properly coordinated. The kernel manages a number of IPC methods. Shared memory is used when two tasks need to pass data between them. The OS/2 clipboard is a good example of shared memory. Data which is cut or copied to the clipboard is stored in shared memory. When the stored data is pasted into another application, that application looks for the data in the clipboard’s shared memory area.
- Named pipes can be used to communicate data between two programs. Data can be pushed into the pipe by one program and the other program can pull the data out of the other end of the pipe. A program may collect data very quickly and push it into the pipe. Another program may take the data out of the other end of the pipe and either display it on the screen or store it to the disk, but it can handle the data at its own rate.
- Semaphores can be used to coordinate the activity of two programs or two separate threads within a single program. When one task sets the semaphore, for example, the other task cannot proceed until the first has reset the semaphore.
- Device management.The kernel manages access to the physical hardware through the use of device drivers. Access to physical devices must be managed carefully or more than one application might attempt to control the same device at the same time. The OS/2 kernel manages this so that only one program actually has control of or access to a device at any given moment.One example of this is a COM port. Only one program can communicate through a COM port at any given time. If you are using the COM port to get your e-mail from the Internet, for example, and try to start another program which attempts to use the same COM port such as HyperAccess Lite, the OS/2 kernel detects that the COM port is already in use. The kernel then uses the hardware error handler (HARDERR.EXE) to display a message on the screen that the COM port is in use.
- I/O Management.The kernel is also responsible for managing I/O devices. This includes parallel and serial port I/O, and file system I/O.The kernel does not actually handle physical access to the disk, but rather manages the requests for disk I/O submitted by the various running programs. It passes these requests on to the file system, whether it be FAT, HPFS, CDFS (CD-ROM file system), or NFS (Network file system), and manages the transfer of data between the file system and the requesting programs.
During the boot process, the kernel is also responsible for loading and processing the CONFIG.SYS file.
Much of the code for actual implementation of these kernel level functions resides in dynamic link libraries such as DOSCALL1.DLL. The command processor, CMD.EXE is also part of the kernel. Some basic command line commands are also included in the kernel as part of the file CMD.EXE. The commands are called Internal commands because they are a part of the kernel. The COPY and DEL commands are examples of internal commands.
Kernel Variations
Over the years, as new versions of OS/2 have appeared, the kernel of the operating system has changed. Most of these changes have been relatively minor to incorporate support for new features or functions.
The primary changes in the OS/2 kernel have been for Symmetric Multi Processing (SMP). All versions of Warp including Warp 3, Warp Connect, and Warp 4, have a uniprocessor kernel. Warp Server has a uniprocessor kernel. Warp Server SMP has an SMP kernel. Warp Server for e-business is shipped with both the uniprocessor and the SMP kernel. When installing Warp Server for e-business, you can select whether to install the uniprocessor or the SMP kernel.
Recommendation: When installing Warp Server for e-business, it is a valid choice to install the SMP kernel on a uniprocessor computer. Because the uniprocessor kernel is somewhat faster on a uniprocessor system than the SMP kernel is, I recommend installing the uniprocessor kernel on a uniprocessor system.
OS/2 Multitasking
Introduction to Multitasking
At any given moment in time, a personal computer microprocessor can execute only one instruction in one task. However, by dividing the microprocessor time between multiple tasks, it is possible to give the impression to relatively slow human senses that they are running simultaneously. This technique is called multitasking.
DOS is intrinsically a single tasking operating system. This means that it can only perform one task, or job, at a time. If you wish to run an application program other than one which is currently running, you must terminate the current application and then start the second application. This limitation, as much as the limitation on memory usage, is due to the historical roots of DOS. The original Intel 8088 microprocessor did not have the hardware support required to effectively implement a multitasking, virtual memory, or memory isolated operating system.
OS/2 utilizes the built in multitasking capabilities of the Intel 80×86 family of microprocessors. These capabilities include the ability to address large amounts of real memory – up to 4 GB – and the ability to protect the system resources being used by one program from intrusion by another program. For this reason, the operating mode of the 80×86 microprocessors which provides for multitasking is known as protect mode.
The multitasking ability of OS/2 allows the system to perform more than one task at a time. You may have several different programs running at once, as well as multiple communications sessions. It is also possible to have one program performing several tasks simultaneously. The basic unit of program execution is the thread. Each program running under OS/2 must have at least one thread, but may have more than one if it has been so designed.
Processes and Threads
The minimal benefit of being able to switch from one program to another without terminating the first is something which everyone can appreciate. The real benefits of true multitasking become apparent when downloading several large files from a BBS, using FTP to transfer a file to the internet, spell checking a large document, and printing checks for accounts payable. The downloads, spell check, and check printing can be started and then you can work interactively with the word processor while the other tasks proceed in the background.
The benefits derived from using multiple threads in a single program are not so apparent, however. From the standpoint of the user, the primary benefit is that of faster perceived program response time. The programmer may provide one thread to allow for data input, another thread for updating the screen, and yet a third for performing calculations. In a spreadsheet environment, for example, as soon as a user has entered a number into a cell, the display can be updated with newly calculated values and while the user is entering additional data, the background thread can recalculate the rest of the spreadsheet. This results in a much faster perceived speed of operation because the user does not have to wait for the entire spreadsheet to recalculate before additional data is entered.
When each program is launched Warp creates a new process. Every process (program) has at least one thread. If the programmer of an OS/2 program decided that multiple threads were required, he or she could use special function calls within OS/2 to do so. In general, programs have only one thread unless the programmer has overtly designed the program for more.
Task Management
OS/2 multitasking is managed by the task dispatcher. The dispatcher handles the dispatching of tasks with a set of algorithms which are designed to allow multiple tasks to run simultaneously with as little effect upon each other as possible, while still allowing high priority tasks swift access to the processor when needed. OS/2 is a dynamic, priority based, preemptive multitasking system with round-robin scheduling.
In OS/2 Warp, the dispatcher dynamically modifies a thread’s time slice based on trigger actions that may have occurred. For instance, if a thread encounters a page fault during its time slice, it is given an extra time slice to process the data contained in the faulted page. Applications doing disk I/O are also given extra time slices if the data they are reading is in the disk cache. When the TIMESLICE= parameter is used as in versions 1.x and 2.x of OS/2, none of these dynamic modifications of a threads allocated time will occur. Instead, each thread will be given the minimum time slice of X, and its time slice will not be allowed to go beyond value Y. See also the TIMESLICE document for more details about this CONFIG.SYS file parameter.
Priority Based Multitasking
A priority based multitasking operating system is one in which each task is assigned a priority. The priority of each task is determined by the programmer. If the programmer makes no overt choice, the operating system, OS/2 in this case, assigns a default priority, regular class, priority level 0.
In any priority based task scheduling operating system, the task with the highest priority which is capable of running, that is, not blocked, will get the CPU. All other tasks must wait until that task becomes blocked before they may have CPU time. A task becomes blocked when it must wait for input from a keyboard or mouse, for example, or for data to be read from a disk, or for a communications buffer to fill. There are many other reasons why a task might become blocked. If a task of a higher priority than the current running task becomes unblocked, then OS/2 will preempt the running task to give the CPU to the task with the higher priority.
OS/2 has four priority classes:
- Time critical (800) A time critical task such as communications or networking will run in this priority class. Such programs need to have access to the CPU very quickly.
In communications, for example, when the data receive buffer fills up it is necessary to remove the data from it and store it in a less critical location until it can be processed by a lower priority task. When the receive buffer fills, the communications port hardware generates a hardware interrupt which is handled by the OS/2 device driver for that port. For an asynchronous communications port this is the COM.SYS device driver. The device driver sends a software interrupt to the application program which moves the data from the receive buffer and stores it in another location in memory.
The portion of the program which handles the communications buffer must be a very high priority so that it can get the data from the buffer before more data arrives and causes a receive buffer overrun. The rest of the communications program can run at a lower priority class. When overruns occur, the data must be resent which reduces the total data transfer rate.
Time critical tasks take a very small portion of the CPU’s time. Even after all time critical tasks receive all the CPU time they require, there is still plenty of time left for all the other tasks running on the computer.
- Server (400) Server class programs are used by Warp Server, for example, to process requests for data by client workstations and to get the data requested ready to transfer across the network. Processing these types of tasks at the Server class ensures that administrative tasks such as creating new user IDs do not interfere with them.
- Regular/normal (200) Regular, or normal class is the priority class at which most application programs run. This is also the default class at which OS/2 will run programs which do not overtly specify a priority class.
- Idle time (100) A program which runs at idle class will only receive CPU time when all other programs at higher priorities have become blocked. In reality, for most average systems, this can be quite a large amount of time. To see this, start the OS/2 Pulse program applet which comes with OS/2. It is located in the Productivity folder. Most of the time the processor is doing very little, if anything, so there is lots of time for idle class programs to run.
The Pulse program itself runs at idle priority. It simply counts the CPU cycles which it receives as a consequence of the fact that no other process needs them, and displays the result as a graph indicating the amount of CPU time being used by all the other programs on the system. To perform this task accurately, it cannot run at regular class or higher because it would always receive some CPU cycles in the normal round-robin sequence of task dispatching. This would skew the results.
A good example of a productive application which should be run at idle class would be a math intensive calculation. There is an OS/2 program which calculates the common math constants Pi and e (Euler’s constant) to any number of decimal places in increments of 500 places. Suppose I want to calculate Pi to 1,000,000 decimal places. At the same time, I want to do all my normal daily tasks like word processing, Lotus Notes, network communications, and asynchronous communications.
Since this calculation takes a couple days on even a fast system, I cannot afford to have it tie up my system. This program was written so that I can change the priority class, so I set it at idle class and start the calculation. Actually, this program was written so intelligently that I can change the priority class while it is calculating. With the Pi calculation going in the background in idle class, I can go do my regular daily work. Any CPU cycles not needed for my normal work are given by Warp to the Pi calculation.
Figure 1: The 4 priority classes of Warp each have 32 levels.
32 Priority levels per class
Figure 2.1.1, above, shows the four priority classes of OS/2 Warp. The boxes to the right of the priority class diagram represent threads of several processes which are running. Threads on the same line are at the same priority class and level. Threads shown with red rectangles are blocked; that is, they cannot run because they are waiting for some system activity, such as disk access to complete, or the printer to request more data. The threads indicated by yellow rectangles are capable of running, but are not currently running because another thread is. The one thread represented by a green rectangle is running. Only one thread can run at a time.
Each priority class under OS/2 has 32 priority levels numbered from 0 through 31. There are a total of 128 discrete priority levels at which tasks can run. This means that multiple tasks may run in regular class, for example, but one or more may still be at a higher priority level within the regular class. The numeric values for each priority class are given in Table 2.1.1.
Priority Class | Numeric Range |
---|---|
Time Critical | 800 – 831 |
Server | 400 – 431 |
Regular | 200 – 231 |
Idle | 100 – 131 |
Using PSTAT to determine the priority of a task
Warp has a utility called PSTAT which allows you to display or print a list of all the tasks and threads running on your system. PSTAT shows the process and thread IDs for each task as well as the priority level for each task. Figure 2.1.2 shows the output of PSTAT when run on the author’s system. The command below issued from the command prompt sends the output of the command to a file named C:\PSTAT.DAT. The /C parameter is used to display the current process and thread data. Other parameters allow display of memory, DLL, and semaphore information.
PSTAT /C > C:\PSTAT.DAT Process and Thread Information Parent Process Process Session Process Thread ID ID ID Name ID Priority Block ID State 002F 0000 13 C:\IBMLAN\SERVICES\ALERTER.EXE 01 0200 FFFE004C Block 002E 0000 13 C:\IBMLAN\SERVICES\TIMESRC.EXE 01 0200 FFFE004A Block 002D 0000 13 C:\IBMLAN\NETPROG\RNS1.EXE 01 0200 FFFE0048 Block 02 0200 06880096 Block 03 0200 068800C2 Block 04 0200 068800EE Block 002B 0000 13 C:\IBMLAN\SERVICES\NETLOGON.EXE 01 0200 FFFE0046 Block 02 0200 FFFD0072 Block 03 031F FFFE0045 Block 04 0200 040054FE Block 002A 0000 13 C:\IBMLAN\SERVICES\NETSERVR.EXE 01 0300 FFFE003E Block 02 0300 FFFE003C Block 03 0300 FDF2BB44 Block 04 0200 FDF254B8 Block 05 0300 FFFE003F Block 0029 0000 13 C:\IBMLAN\SERVICES\NETSERVR.EXE 01 0301 FFF78083 Block 02 0300 FFFE003D Block 03 0300 040054E6 Block 04 0300 FFFE0040 Block 05 0300 04004853 Block 06 0301 FFFE0041 Block 0026 0000 13 C:\MUGLIB\MUGLRQST.EXE 01 0200 040054C8 Block 02 0200 FE1ACE34 Block 0025 0000 13 C:\IBMLAN\SERVICES\MSRV.EXE 01 0200 040054BC Block 02 0200 FFFE0037 Block 0023 0000 13 C:\IBMLAN\SERVICES\WKSTAHLP.EXE 01 031E 2260BE6C Block 02 0200 225005FE Block 03 031E 2250210E Block 04 031E 2250061C Block 0022 0000 13 C:\IBMLAN\SERVICES\WKSTA.EXE 01 0300 FFFE003A Block 02 021F FFFD005B Block 03 0200 FFFE0033 Block 04 021F FFFD0060 Block 0018 0000 00 C:\OS2\EPWMUX.EXE 01 0200 FFFE0024 Block 0013 0000 00 C:\OS2\EPWMUX.EXE 01 0200 FFFE001F Block 0012 0000 00 C:\OS2\EPWPSI.EXE 01 0200 06880012 Block 0011 0000 00 C:\OS2\EPWMP.EXE 01 0200 FE03E834 Block 02 0200 FFFE0025 Block 03 0200 FFF78083 Block 000E 0000 00 C:\WAL\MEMMANIT.EXE 01 031F FFFE0016 Block 000C 0000 00 C:\IBMLAN\NETPROG\ATKINIT.EXE 01 0302 FFFE0013 Block 02 0200 FFFE0014 Block 000B 0000 00 C:\IBMCOM\VLANINIT.EXE 01 0200 FFFE0017 Block 000A 0000 00 C:\OS2\EPWROUT.EXE 01 0200 FFFE0020 Block 02 0200 FFFE001A Block 0009 0000 00 C:\OS2\SYSTEM\LOGDAEM.EXE 01 021F 04A00252 Block 0008 0000 00 C:\IBMLAN\NETPROG\LSDAEMON.EXE 01 0200 FFF78083 Block 0007 0000 00 C:\IBMCOM\PROTOCOL\LANDLL.EXE 01 030B 544F4B52 Block 0005 0000 00 C:\MPTN\BIN\CNTRL.EXE 01 0304 F2750002 Block 02 0304 F2750001 Block 03 0304 1450525A Block 04 0304 14505272 Block 05 0304 F2750001 Block 06 0304 F2750002 Block 07 0304 FFF78083 Block 08 0304 F2750008 Block 0004 0000 00 C:\IBMCOM\LANMSGEX.EXE 01 0200 FFFEF636 Block 000D 0001 01 C:\OS2\PMSHELL.EXE 01 0200 FDF20F24 Block 02 0300 FFCA000D Block 03 0300 FFFD001C Block 04 0300 FFFD001D Block 05 0300 04000E28 Block 06 0200 FE179B6C Block 07 0200 FE17BBF0 Block 08 041F FDF20F54 Block 09 0200 FFFE001B Block 0A 0200 FFFD0006 Block 0B 0300 FFFE001D Block 0C 0300 FFFE001E Block 0D 0300 FFFE001C Block 0E 0304 FFFD002A Block 0F 0304 04000E1A Block 10 0200 FFFD002C Block 11 0301 FDF25078 Block 12 0200 FDEDAD40 Block 13 0300 04000E36 Block 14 0300 FE03DB74 Block 15 0300 FDF254F8 Block 16 0401 FE1E037C Block 17 0401 FE1E0DA8 Block 00A0 000D 15 F:\IMPOS20\IMPOS.EXE 01 0200 FE1F16EC Block 02 0200 0688011A Block 0093 000D 1E E:\DESCRIBE\OS2\DESCRIBE.EXE 01 021F FE1E6E38 Block 02 0200 FE1E6BC8 Block 03 0200 FE1E6BF4 Block 04 021F FE1E1980 Block 05 0200 FE1E200C Block 06 0200 FE1E2A30 Block 008E 000D 1D (kernel) 01 0200 FE1E08D4 Block 0055 000D 1C E:\UTILITY\FILESTAR\FILESTAR.EXE 01 0200 FDEF5C30 Block 03 0200 FDEF5990 Block 04 0200 FDF0FACC Block 004B 000D 18 F:\NOTES\ILNOTES.EXE 01 0201 FE01ADF0 Block 004A 000D 1B F:\NOTES\QNC.EXE 01 0200 FDFE7F68 Block 0048 000D 1A E:\IBMAV\IBMAVTIM.EXE 01 0200 FFF78083 Block 0047 000D 11 E:\WPC200\WPC200.EXE 01 0200 FE1C2BEC Block 02 0200 FE1C29D0 Block 03 0200 FE1C2948 Block 04 0200 FE1C292C Block 0034 000D 13 C:\OS2\CMD.EXE 01 0200 FFCA0034 Block 00AA 0034 13 C:\OS2\PSTAT.EXE 01 031F 00000000 Running 0032 000D 04 F:\NOTES\QNC.EXE 01 0200 FE18C7B0 Block 0033 0032 04 F:\NOTES\ISERVER.EXE 01 0201 FFF78083 Block 02 0206 FFF78083 Block 03 0207 040054DA Block 04 0207 040054D4 Block 05 0201 FFF78083 Block 06 0205 FE1B71F0 Block 0045 0033 04 F:\NOTES\QNC.EXE 01 0206 FE1C4D88 Block 0046 0045 04 F:\NOTES\IADMINP.EXE 01 0201 FFF78083 Block 0041 0033 04 F:\NOTES\QNC.EXE 01 0206 FDEFDC70 Block 0042 0041 04 F:\NOTES\IAMGR.EXE 01 0201 FFF78083 Block 0043 0042 04 F:\NOTES\QNC.EXE 01 0201 FDEFDB64 Block 0044 0043 04 F:\NOTES\IAMGR.EXE 01 0201 FE136AAC Block 003C 0033 04 F:\NOTES\QNC.EXE 01 0206 FDFF3F70 Block 003D 003C 04 F:\NOTES\IUPDATE.EXE 01 0201 FFF78083 Block 003A 0033 04 F:\NOTES\QNC.EXE 01 0206 FE1B0D58 Block 003B 003A 04 F:\NOTES\IROUTER.EXE 01 0201 FFF78083 Block 0038 0033 04 F:\NOTES\QNC.EXE 01 0206 FE1C2864 Block 0039 0038 04 F:\NOTES\IREPLICA.EXE 01 0201 FFF78083 Block 001F 000D 19 E:\IBMAV\IBMAVSD.EXE 01 0200 FE040FCC Block 001C 000D 17 E:\UTILITY\GTU30\SENTRY.EXE 01 0200 FDF1B27C Block 02 0200 FFF78083 Block 03 0200 FFF78083 Block 04 0200 FFF78083 Block 05 0200 FFF78083 Block 001B 000D 16 E:\FAXWORKS\FAXWORKS.EXE 01 0200 FE10AECC Block 02 0300 FDEDA968 Block 03 0200 0688006A Block 04 0200 FFFE002F Block 05 031F 00BC09E4 Block 0019 000D 14 C:\IBMLAN\NETPROG\NETMSG.EXE 01 0200 FDFF1CC0 Block 02 0200 FFFE0039 Block 03 0200 FE126BCC Block 04 0200 FDFF1EE8 Block 0016 000D 12 C:\OS2\PMSHELL.EXE 01 0200 FE18CA20 Block 02 0300 FDEDA614 Block 03 030A FDEDA5FC Block 04 0300 FE18C7B4 Block 05 0300 FE17CE68 Block 06 0200 FDEDAD58 Block 07 0400 FE141FD8 Block 08 0200 FE122D34 Block 09 0200 FE122C30 Block 0B 0400 FE18C050 Block 0C 021F 43D82800 Ready 0D 0200 FFFE0026 Block 0E 0400 FE11FF54 Block 0014 000D 10 C:\OS2\PMSPOOL.EXE 01 0200 FFF78083 Block 02 0200 FE149BC4 Block 03 0200 4388000E Block 04 0200 FE18DFF0 Block 05 0200 FE150970 Block 06 0200 FE1509A8 Block 000F 000D 00 C:\OS2\SYSTEM\HARDERR.EXE 01 0300 04000E44 Block 02 0300 04001158 Block 03 0300 0400117C Block
Figure 2: The results of PSTAT on the Author’s system.
Altering Priority Levels
OS/2 does not provide for user access to priority levels. A programmer, however, may provide access to priority levels within a program and provide the user with controls in the program to manipulate them. There are also some third party utilities available which allow the user to view and alter the priority levels of other running programs. One such utility is CPU Monitor Plus, by BonAmi Software.
Extreme care should be taken when altering the priority level of a process or thread, as the action taken may have the opposite of the desired effect. Consider, for example, the print spooler process. This process manages the transfer of print data from application programs, to the hard drive, and from there to the printer.
When I ask most people what priority they think that the spooler process should run at, they tell me it should be a very low priority process. In fact, it should be a high priority process. The reason for this is that printing, being an essentially mechanical process, is very slow compared to the speed of the processors in today’s computers. As a result, when the spooler sends data to the printer, it must then wait for a computer’s eternity for the printer to print the data and request more from the spooler. When this request for more data is received by the spooler, it is important to respond and get the data to the printer as quickly as possible to prevent delays to an already slow process.
The spooler is blocked most of the time, either waiting for a print job or waiting for the printer to request more data for a running print job. While blocked, it gets no CPU time, and all five spooler threads have priority level 200, the base level of the Regular priority class. When a print job is spooling, however, one of the threads is boosted to priority level 400, the base level of Server (a.k.a. Fixed High) class. This provides a high enough priority to ensure that printing gets done quickly but, because the spooler is blocked most of the time waiting for the printer to request more data, it does not affect the performance of the rest of the system.
The Spooler object in the System Setup folder allows users to adjust the priority of the print spooler. You should be careful with this, however. Decreasing the priority will slow the print process significantly. Increasing the priority will have no noticeable effects while small print jobs are printing because they complete so quickly, but can cause the rest of the system to slow considerably while very large print jobs are being printed. Another problem with increasing the priority too much is that the spooler priority becomes higher than that of other important tasks such as network functions. This can cause problems not only with the response time on the local workstation, but it can also create problems for networking tasks.
The default print spooler priority setting is perfect for most environments.
Preemptive Multitasking
In any multitasking operating system, there are some tasks which are extremely important and which must obtain access to the processor as quickly as possible at specific times. Such a task would be a communications or networking program. These tasks, or really a small portion of these tasks, the portion responsible for the time critical part of the process, should be run at a high priority. For communications programs this is usually at some high level in the time critical class.
When a program with a higher priority than the currently running program or task becomes unblocked, OS/2 preempts the lower priority task and gives the CPU to the higher priority task.
Round-Robin Scheduling
Round-robin scheduling simply means that all tasks which are running at the same priority will receive time slices in a round-robin fashion, so that each can have some time. The Warp task dispatcher manages this and preempts any task which has taken the maximum time slice.
Dynamic Priority
The priority level at which a task runs under OS/2 is dynamic; OS/2 can change the priority of a task depending upon its needs. There are three ways in which OS/2 uses it’s ability to dynamically alter the priority of applications, even while they are running.
CPU Starvation
It is possible that some tasks in a multitasking system might become starved for CPU time. Since most running tasks will be at regular priority, many will be at the same priority level. As these tasks run in round-robin fashion, the amount of time taken by the tasks which are not blocked may prevent one or more of the remaining tasks from obtaining CPU time within the amount of time specified in the MAXWAIT statement in CONFIG.SYS.
When a task becomes starved for CPU time in this manner, the OS/2 task scheduler boosts the priority of the starved task within its class by one priority level. This places this task at a higher priority level than the other tasks with which it was running. It will, therefore, receive a timeslice before those other programs. When it does receive a timeslice, it is allocated one minimum timeslice by the scheduler and then it is reduced to its base priority.
This dynamic priority scheduling allows each task to be sure it will receive at least some CPU time.
Foreground Boost
When running a program in a multitasking environment, especially one with which you will continually interact such as a word processing program, it is reasonable to expect that program to respond to user input quickly. One of the ways in which OS/2 ensures that this will happen is to provide the foreground task, that is the one with which the user is interacting and which has the keyboard focus, a boost in priority. In this case the boost is by a level of one within the task’s priority class.
Foreground I/O Boost
Setting PRIORITY_DISK_IO=YES in CONFIG.SYS provides a priority boost to I/O operations for the application running in the foreground. This ensures that a DOS program, or an OS/2 program which was not written with a separate thread for I/O operations will perform its I/O tasks and return control to the user as quickly as possible.
OS/2 Crash Protection
This section discusses the term Crash Protection and what is meant by Crash Protection within the context of the OS/2 operating system. It also discusses why applications crash, the causes of OS/2 crashes, and methods which can be used to ensure that crashes of the operating system can be minimized.
Crash Protection
IBM began talking about OS/2 and its crash protection in early 1992, while OS/2 2.0 was in beta testing. IBM states on the OS/2 Warp package that “[OS/2's] Crash Protection helps prevent a single, wayward program from affecting the rest of your system.” Notice that the term Crash Protection is a trademark of the IBM Corporation. IBM thinks that this is so important that they want no one else to use the term. If Crash Protection so important, and if OS/2 has it, why does OS/2 still crash?
Application crashes
Application programs can and do crash. In many cases in which an application actually crashes, the problem is a programming error of some type. The short C++ program in Figure 1 is an example of a program which may crash under some circumstances. This program is designed to request a name as input. The variable “Name” is defined as a three character string. Most users will type their own name, and names vary in length. The program will cause an access violation and SYS3175 error if the user enters a name with more than three characters. Thus it will fail for long names and not fail for short ones. The SYS3175 error message is displayed in a PM dialog box. It is also possible to get SYS3170 , SYS3171 , or SYS1808 errors depending upon the length of the name entered.
#include <iostream.h>
void main()
{
char Name[3];
cout << endl << "Enter a name: ";
cin >> Name;
cout << endl << "The name you entered is: " << Name <<"." << endl;
}
Figure 1: This C++ program can crash under the right circumstances.'
In the case of a three letter name like “Don”, the program displays a text line which says, “The name you entered is: Don.” No error occurs. With a four letter name, like “Dave”, the program crashes and OS/2 displays a dialog box which says that a SYS3171 error has occurred. If the user chooses to view the register display from the dialog box choices, he or she will find that the error detail is “exception c0000005… insufficient stack space”.
Now assume that the user enters a fifteen letter name. The program crashes again and the user is presented with a dialog box which says that a SYS3175 error has occurred. This time viewing the register display shows that the error is an “…access violation…”. This program has also generated a SYS3186 error, which is a “privileged instruction” error when used with the name “Jennifer”, for example.
In all cases, when the error occurs, the program crashes. In no case does OS/2 crash and all of the other applications running on the system continue to run as if nothing has happened. As far as the other programs running on your system are concerned, nothing has happened because they were protected from the crash of the defective program. This is what crash protection means and OS/2 fulfills this promise quite nicely. This program would also crash in a DOS or Windows environment, but the entire system would crash and recovery would usually necessitate rebooting the system.
There are some very interesting conclusions which can be drawn from this little experiment. The first is that a single bug in a program can cause a number of different symptoms. In this case, at least five different errors have been presented.
The second conclusion we can make is that a bug may not necessarily present itself and cause a symptom; at least not until the proper circumstances are present. This situation can occur in a real program in which a programmer did not fully consider the size of a data field. The name field in a payroll program may work fine for years – until a new employee with a very long name is hired. An error occurs while entering the new employee into the payroll program, and the payroll clerk calls the company support person with this “new” bug. In many cases, the assumption is that the program is still fine, but the hardware is at fault, or that OS/2, which was installed last week, is now the problem.
Application lockups
OS/2′s multitasking uses a priority based, round-robin, preemptive algorithm. This means that OS/2 will give the CPU to the task with the highest priority. If another task is running at a lower priority, that running task will be preempted by OS/2 in order to do so. OS/2 will not allow a lower priority task to run until the higher priority task has completed.
A poorly written OS/2 application can take up all the CPU time and cause the entire system to lock up. Figure 2 contains a C program which operates entirely within the rules of OS/2 and its programming APIs, but which will lock up the system as soon as it begins to run. This program boosts itself to the highest priority in the system and loops in a math operation. This prevents OS/2 from allowing any other application CPU time.
#define INCL_DOSPROCESS
#include <os2.h>
#include <stdio.h>
#include <math.h>
int main(void)
{
double value, result;
ULONG Scope, count;
ULONG PriorityClass;
LONG PriorityDelta;
ULONG ID;
APIRET rc;
PriorityDelta = 31; /* delta to process priority */
ID = 0; /* Current process */
value = 236723;
rc = DosSetPriority(PRTYS_PROCESS, PRTYC_TIMECRITICAL, PriorityDelta, ID);
if (rc != 0) {
printf("DosSetPriority error: Return Code = %ld", rc);
return;
}
for (; ; ) {
result = sqrt(value);
} /* endfor */
}
Figure 2: This program will lock up OS/2 by hogging all the CPU cycles
On rare occasions, a program may enter a high priority section of code and get stuck there. This can cause a complete system lock up. In other cases, the program will stay in the high priority section for several seconds or even minutes. This is not good programming, but it happens. Waiting a few moments will bring the system back to normal when the program causing the problem reduces its priority back to normal or completes execution of the high priority thread.
It is important to note that code can be written which can cause any operating system to lock up or crash. In most real world applications, the priority of a task is boosted temporarily and other applications and tasks will not even be affected. Other applications use a separate thread for high priority activities. These threads only need to execute for very short period of time and the effect on the rest of the programs running in the system is negligible.
The Single Input Queue Dilemma
Another cause of OS/2 crashes is the single input queue (SIQ) design of the Workplace Shell (WPS). The single input queue simply means that all of the mouse input and keystrokes sent to the WPS are sent to a single queue to wait until they can be processed by the application for which they were intended. This means that an application which was not written to properly respond to the queue and release it immediately can cause the entire desktop to lock up. Memory overcommitment of 100% (when total system memory requirements are 200% of installed RAM memory) or more also seem to contribute to the single input queue lockup problem.
In reality, OS/2 is not locked up; only the desktop is frozen. The processing of other applications continues so that if you have a print job spooling or a download from a BBS in process, those tasks continue to run. You can see this if you start the OS/2 System Clock and configure it to show the seconds hand. If your system locks because of the single input queue, the second hand on the clock will continue to run. You may wait until critical apps or downloads have finished before you reboot the system, if it actually comes to that.
The single input queue was designed into OS/2 by Microsoft back in days of OS/2 1.1, the first version to have the Presentation Manager desktop environment. This was done because – so the story goes – the programmer responsible for the Presentation Manager did not know how to deal with multiple input queues. With multiple input queues, each application has a separate queue for mouse and keyboard activity, so that a single misbehaved application does not lock up the entire WPS. Microsoft has used a multiple input queue strategy in Windows NT and Windows 95 to overcome this problem.
IBM has not modified OS/2 to provide multiple input queues because they contend that would break existing OS/2 applications which depend upon the single input queue model. IBM has said, however, that they intend to fix this problem, and appears to have included the circumvention in Fixpak 17 which became available in late January, 1996. The fix is not multiple queues, but rather a watchdog timer on the single input queue which will release the queue automatically when one application refuses to respond.
There is a great deal of controversy over whether this approach to the solution results in a true fix or merely a workaround. If it works, however, the specific approach used is irrelevant. Fixpak 16 is also supposed to have had the SIQ fix, but has been withdrawn because it had some problems. If you have a copy of it, you should not install it. Fixpack 17 does contain the SIQ fix. The fix is described in the text file READ17_1.TXT which is included with the fixpack. The following line must be added to the CONFIG.SYS file to activate the fix.
SET PM_ASYNC_FOCUS_CHANGE=ON x
The x parameter specifies in milliseconds the amount of time which OS/2 waits before determining that the application is not responding. The default with no parameter is 2000 milliseconds (2 seconds). The suggested range is from 2 to 5 seconds. Once it has determined that a program is not responding to the queue, OS/2 flags the queue as bad and switches to the next application you are trying to use.
OS/2 continues to monitor the queue to see whether the application begins to respond by reading messages. If this occurs, OS/2 marks the queue as good and continues to operate normally. If the application does not respond to the queue, you can try to terminate the program, or just ignore it.
Recovering from hangs and lockups
Once you realize a lockup has occurred, you should spend a moment before taking any action to observe what is actually happening. Some apparent lockups are caused by normal activities like disk swapping. When launching a program with memory already significantly overcommitted, a large amount of swapper activity will occur. Since this activity must take priority over all else except communications, the system may seem to come to a halt. Heavy disk activity might indicate that the system is engaged in serious swapping rather than being locked up.
There are a couple ways of recovering from OS/2 system hangs and lockups caused by the software types of problems we have discussed so far. First, press the Ctrl-Esc key combination repeatedly. This will normally result in a dialog box which prompts you to terminate the application. If you try this it may result in termination of the hung program and negate the need for a reboot. Be sure to wait for several minutes before proceeding with any more drastic actions because OS/2 can take a very long time to respond to Ctrl-Esc. Ten or fifteen minutes would not be unreasonable to wait on a slow (less than 486 33 MHz) system; five or six minutes would be appropriate on fast computers. Warp’s response to Ctrl-Esc seems much faster with Fixpak 16.
WatchCat
WatchCat is a shareware program written by a pair of programmers in Germany which can help in the recovery from some OS/2 lockup situations. When a computer with WatchCat installed locks up, the user generates a wake-up signal using one of several methods. A device driver is installed which allows WatchCat to respond to a user selected keyboard combination, or it can be configured during or after installation to respond to mouse or joystick input, or to switches connected to the serial or parallel ports, or other custom devices. Once WatchCat has control of the system in a full screen or windowed text mode session, the locked application can be terminated. By their nature, some types of applications cannot be terminated. The registered version can terminate more applications more “brutally”, and has more activation methods and other features.
WatchCat is intended to kill programs which are not responding to input, and therefore, to free the input queue. It seems to do a good job of this. WatchCat cannot, however, help with programs which hog the CPU by running at high priority. The program in Figure 2, for example, cannot be terminated because WatchCat cannot get any CPU cycles. I also found it necessary to use the key combinations several time to get WatchCat’s attention. The documentation suggests an alternative activation method when this occurs
If terminating the locked program does not work, you can reboot using the Ctrl-Alt-Del key combination. This soft reboot will be intercepted by the OS/2 kernel and flush the cache and buffers to disk before terminating OS/2 and performing the reboot. This is not a wonderful “recovery” but you should not lose any data and all files will be closed properly.
If a soft reboot does not work, the chances are very high that you do not have a software problem, but rather a hardware problem such as a lost interrupt. You can also tell when the system has entered a “hard lock” because the second hand of the OS/2 system clock will stop. Hardware causes of OS/2 crashes are discussed in following sections. When other attempts at recovery don’t work, you will have to reboot with the Big Red Switch.
Other causes of crashes
There are a number of other causes for system crashes. These are not unique to OS/2, however, and can affect any computer running under any operating system. The bus design of your system is important and the environment in which your system operates is also consequential.
System design
One area which can cause problems is the design of your system, particularly the system data bus. The original IBM PC data bus is called the ISA bus. ISA stands for Industry Standard Architecture – even though it is not an industry standard. The ISA bus was developed, along with the original IBM PC and DOS, based on the assumption that the PC would be used in a stand-alone, single tasking environment. As a result, the nature of the ISA bus is not conducive to a multitasking operating system.
In a true multitasking environment many different tasks can be under way at any given time. This can result in a large number of interrupts being generated. It is possible with the ISA bus for an interrupt to be lost if it happens to occur at the same time as another interrupt. A lost interrupt causes the system to hang or lock up. Many times, OS/2 hangs on an ISA bus system are symptomatic of old hardware technology.
IBM developed the Micro Channel bus for its PS/2 line of computers with a multitasking environment in mind. It is designed so that an interrupt cannot be lost, even if it coincides with another interrupt. Far fewer hangs occur on systems with Micro Channel than on ISA bus systems. The biggest problem with the Micro Channel bus is that IBM did not and does not know how to market personal computer products. The PCI bus which is becoming widespread in systems today is also designed to provide a better multitasking hardware platform than the ISA bus. Not only is it significantly faster than the ISA bus, it also helps to prevent lost interrupts.
If you have a choice, you should purchase a system with a Micro Channel bus or a PCI bus to eliminate lost interrupts. These two busses are also designed to reduce problems caused by Electromagnetic Interference (EMI).
Electromagnetic Interference
Environmental problems for computers are similar to environmental pollution for human beings and other living things. Electronic pollution is called Electromagnetic Interference, or EMI. Electromagnetic interference is caused by two types of electromagnetic fields; radio frequency fields and magnetic fields. This class of phenomena affects the system hardware, but many of the symptoms can appear to be the result of problems in the operating system. Any operating system can be affected, OS/2, DOS, Windows NT, AIX, Unix, and Windows 95.
There are a number of different electromagnetic phenomena which can cause problems for computers and other electronic equipment. Electrostatic discharge (ESD) can occur in the Autumn and Winter. Radio frequency interference (RFI) can occur near radio and TV stations, radar installations, airports, and other locations as well. Poor grounding can cause problems of its own and it can aggravate other problems like ESD and RFI.
Electrostatic Discharge
Electrostatic discharge (ESD) begins to show up in the Autumn as the moisture content of the air – relative humidity (RH) – decreases. During the summertime the high relative humidity keeps ESD at bay by draining the electrostatic charges almost as quickly as they accumulate.
Electrostatic charges are created when two dissimilar materials are separated. The most commonly recognized method for people to accumulate a static charge is to walk across a carpet on a dry autumn or winter day. The static charge accumulated on such a day is not noticeable until it is discharged to another object – usually a door knob or the computer – with the crackle of a spark which causes an unpleasant jolt.
ESD can cause a computer to crash in many ways. You may find that your computer just hangs. You may experience parity errors in DOS or Trap errors in OS/2. Windows may present a general protection fault (GPF) as the result of ESD. The symptoms will vary and the true source of the problem will be very difficult to determine.
The case in which static is discharged from your body is probably the least common cause of problems for your computer. The charges accumulated are just not that high. The real culprit is your chair. A charge of up to 10,000 volts is generated when you get up out of the chair – remember the separation of dissimilar materials. The charge is retained by the chair because the casters on most chairs are rubber or plastic – both of which are nearly perfect insulators. When the chair touches or comes in close proximity to the desk or cart on which your computer sits, the resultant electrostatic discharge can and frequently does disrupt its operation.
Simple ways to prevent ESD
There are only a couple things you can do to prevent ESD. You can also take steps to ensure that when ESD does occur, the results are as harmless as possible.
The primary and least expensive thing that anyone can do to reduce the occurrence of ESD is to prevent the buildup of static charges. The best way to do this is to keep the relative humidity in the computer room between 45% and 70%. 50% to 60% RH is ideal. The 45% to 70% relative humidity range drains away the static charge through the moisture in the air quickly enough that it does not build to a level high enough to cause a discharge.
Another way to prevent static buildup, particularly on your chair, is to use special static draining carpet and chairs with casters which are designed to drain static to the floor and from there to the ground. This is obviously a more expensive solution than keeping the relative humidity in the correct range. It may be necessary, however, to use this approach in buildings or offices in which there is no control over the relative humidity.
There is another very simple way to keep the air in your computer room moist as well as filtered. Green, growing plants add moisture to the air and filter it to remove harmful pollutants and toxins. Plants also remove undesirable ions from the air. These attributes of plants are good for people as well as computers.
Magnetic fields
The magnetic field created by your computer monitor can cause problems when the monitor is placed on top of or in close proximity to your system. All computer monitors use a CRT (cathode ray tube) to generate an image using a beam of electrons. This electron beam is swept across the face of the CRT by a powerful magnetic field which can interfere with the ability of the system to read data from the diskette drive or from any device which has a cable passing too close to the CRT. This can cause CRC – cyclic redundancy check – or other disk media errors.
Almost any type of electrical device can generate a magnetic field. Many of these devices are not computer related. The best way to prevent problems due to magnetic fields is to remove the source of the magnetic field. Move the system monitor away from other devices like the system unit. Keep the entire system away from large electric motors or CRT devices like television sets.
Radio Frequency Interference
Radio Frequency Interference – RFI – is any unwanted electronic signal that is transmitted or received by an electronic device. A computer can generate RFI that interferes with the operation of other electronic devices, just as other devices generate RFI that disrupts the computer. RFI can propagate through the air, as with radio waves, or through the power lines to the power plug of your computer. These unwanted and undesirable signals, whatever their source and however they are propagated, can crash your computer unexpectedly or initiate any number of unusual symptoms.
Symptoms of RFI can be lockups and hangs, trap and SYSxxxx errors of various types, repeated booting, CRC and disk media errors, and internal processing errors. In other words, many of the errors that can be caused by real hardware or software problems can also be caused by RFI problems that are just as real but harder to find, prove, and fix. Many times problems that cannot be traced or explained in any possible way should make you suspicious of RFI.
Sources of RFI
Nearby radio and TV stations can generate powerful electromagnetic signals. These signals propagate through the air and can be picked up by a computer. The cables attached to a computer and to peripheral devices can act as excellent antennae. The keyboard cable, the printer cable, the cables to modems and other external devices all pick up the radiated signals from radio and TV stations. If your system is located close enough to one, you may experience problems.
Powerful radar sources can also affect your system. An airport or air station can be the source of ground-based radar as well as aircraft radars and other radio signals. These radar signals can be powerful and can cause problems similar to those caused by radio and TV signals. The system entry points are cables, which act as antennae for radar signals. Microwave relay towers and cellular phones and their relay towers can cause RFI problems with computers, too.
Minimizing RFI problems
RFI problems cannot be prevented entirely, but they can be minimized by taking certain simple precautions. If you are located next to a radar installation, for example, even proper grounding and all other measures may not be enough to prevent high power radar pulses and radio emissions from interfering with your computer. The following suggestions should help to minimize problems with RFI.
One very common set of entry points for radiated RFI is loose system covers and missing card slot covers. Replace any missing card slot covers. These covers may have been left off after removing a card from the system. Be sure to always replace them when a card is removed from a system. Be sure to install the covers on your system unit or attached peripheral devices if you currently have them off. Fasten them down securely with the latches or screws provided. A missing or improperly installed system cover allows significant RFI entry into the system.
Another common entry point for RFI are the cables that connect the various external peripherals to the system. These cables act as antennae and can pick up radio frequency signals and transmit them inside the system where they can cause problems. These cables can be keyboard cable, mouse cable, serial communications and printer cables, parallel printer cables, audio cables if you have a sound card, data cables to external devices such as external SCSI hard drives or CD-ROM drives, and even the system’s own power cord.
To reduce RFI pickup on cables, ensure that each cable connector is seated properly in its receptacle at both ends of the cable and that the fasteners are properly installed and in use. If screws are used to hold the connector in place, ensure that they are tightened snugly. Where wire retaining clips are used, ensure that they are properly seated and latched. For printer cables that have separate ground wires, you should connect the ground wire to the screw or fastener provided on one end only. Connecting the ground wires on both ends can cause ground loop currents to flow that defeat the purpose of the ground wire. In the case of cables like this, the ground wire is used for shielding, and it makes its connection to the ground reference through the frame of the printer.
Check the ground
Most new homes and office buildings have adequate grounding for the proper operation of a personal computer system, but older homes and offices may not. Be aware, however, that even though a building is relatively new, there still may be problems such as loose connections and missing connections that increase the susceptibility of the system to RFI problems. If you even suspect an EMI problem, check the ground! Computers are much more susceptible to the effects of ESD and RFI when they are improperly grounded. A quick check of your computer’s ground can be accomplished with a simple electrical outlet ground checker available at most hardware or electrical supply stores. Even if the ground checks good, however, you could still have a grounding problem which can aggravate the effects of ESD,
The ideal ground wire installation is an insulated green wire at least the same size as the wires which supply the power to the outlet. The wire should connect only to a one inch diameter copper stake driven at least 10 feet into moist earth or to an equivalent copper water pipe. It should not connect to any other wire or bus at any point along its length. The connection to the ground stake should be made at a point no greater than twelve inches from the entry into the earth, and should be as close as possible to the earth.
Proper grounding is not difficult to achieve, but it can be expensive. You should definitely call a trained electrician to deal with this type of problem. Do NOT under any circumstances attempt to work on the electrical system of your home, office, or building yourself. It can kill you.
If you are having problems which no one can seem to fix, the important things to check are the relative humidity and the grounding of your computer. It would also be wise to consult with someone who specializes in resolving electromagnetic environmental problems.
OS/2 is crash protected
OS/2 does live up to the crash protected claims which IBM makes for it, but it is not crash-proof. Many of the causes of OS/2 crashes are really not problems with OS/2, but rather are the result of external factors which affect all operating systems equally. A true crash – as opposed to a single session lockup – which can be truly attributed to a problem in OS/2 is very rare. OS/2 is a solid platform which gets better with each release.
The Swap File
The swap file is an important part of OS/2 memory management. It allows OS/2 to overcommit memory so that more memory can be used by the operating system and application programs than there is RAM physically present in the computer. Pages of data are swapped out of RAM and onto the disk for storage until they are needed again, when they are swapped back into RAM.
The memory pages stored on disk are located in a file called SWAPPER.DAT, which is usually located in the \OS2\SYSTEM subdirectory on the OS/2 boot drive. The location of this file is specified in the CONFIG.SYS file by the following line, and can be changed if your boot drive is too full to provide sufficient space for the SWAPPER.DAT file to grow.
SWAPPATH=C:\OS2\SYSTEM 4096 5120
The SWAPPATH statement in the CONFIG.SYS file determines the initial size of the SWAPPER.DAT file (5 MB in this example) and the amount of disk space to reserve so that the swap file cannot file up the entire disk. It also determines the location of the swap file.
Swapping Strategy
The strategy used to implement swapping in OS/2 is completely misunderstood by most people. As a result they have certain expectations about how the swap file is supposed to behave, and believe that there is a problem when it does not behave as expected.
OS/2 starts by creating the SWAPPER.DAT file during the kernel initialization. If the swap file previously existed, as is almost always the case, it is erased and recreated. The initial size of the swap file is determined by the second parameter in the SWAPPATH statment, above. Its location is determined by the path specified in the SWAPPATH statement.
Preallocating the swap file helps to ensure that it is contigous. This is especially important for performance reasons on FAT drives. Preallocation also reduces the amount of time required to move data to the swap file because the space on the hard drive has already been allocated. Again, this is especially important on a FAT drive because it can take a great deal of time to allocate disk space. This is a result of the relatively primitive structure of the FAT file system.
Swap File Allocation
Part of the OS/2 swap strategy is to attempt to allocate or deallocate space for SWAPPER.DAT on the hard drive when no other activity is taking place. This helps to ensure that, when additional space needs to be allocated, it is not done at the very time when the data needs to be swapped to the file, thus slowing the actual swapping process.
When RAM is full and existing swap file space is nearly full, the memory management portion of the OS/2 kernel allocates more space on the hard drive for the swap file even though it is not yet needed. The trigger point is when 500 KB or less of free space remains in the swap file. When that point is reached, the memory manager watches the hard drive to determine a time when it is not busy responding to read or write requests. When the drive is not busy, the memory manager allocates more space for the swap file in 1 MB increments.
This strategy for swap file allocation not only prevents having to allocate disk space at the moment the swap file needs to be used, it also prevents interrupting other applications which are accessing the disk.
Swap File Deallocation
Deallocation of swap file space is less critical in terms of its impact on the swap process. Deallocation can occur any time. It does not have to be done as a prerequisite to enable some other task to be completed. It is also desirable to maintain much of the data in the swap file for a period of time after the file was closed or the program terminated. This can prevent having to read those same files from the disk if they are needed relatively soon.
Say, for example, that I have just finished a document in a word processor. After I print the document, and while the print spooler is sending the document to the printer and the printer is printing the document, I close the program. I am prone to make mistakes, as are most of us carbon based, humanoid life forms. Since I find the error after the file is closed and the program has been terminated, I have to restart the word processing program and reload the document. It does not take very long because the application and the document have both been retained in the swap file.
Dynamic Link Libraries (DLLs) are also retained in the swap file for a considerable period of time. Many DLLs are used by a lot of different components of OS/2 and by many application programs.
For these reasons swap file deallocation does not take place quickly. Many people I have talked to in my years of supporting OS/2 assumed that as soon as a file was closed or a program terminated that the swapper file should shrink. When it did not, they assumed that there was a problem. This is an erroneous assumption.
Let us assume, then, that several files or programs have been closed and that the requisite amount of time has passed for the memory manager to begin the process of deallocating space from the SWAPPER.DAT file. When the disk is not busy, space belonging to the files and programs which have been least recently closed is marked as unused. It is not possible, however, just to whack a chunk off the end of the file. Most of the empty space in the file is now scattered throughout the SWAPPER.DAT file rather than all being nice and tidy at the end.
The task of the memory manager now becomes one of moving all of the unused space to the end of the swap file so that it can be deallocated. Over a period of time while the disk is not busy with productive tasks, the memory manager moves empty pages to the end of the swap file by moving in-use pages to the empty ones nearer the beginning of the file.
When three conditions are met, the memory manager will deallocate the space.
- The last 1 MB of space in the file must be unused.
- There must be 1.5 MB of total unused space.
- There must be no new pages swapped into the file for a specified period of time. This helps to ensure that there will be no immediate need to reallocate space in the swapper file. Why deallocate space which will be needed again soon anyway?
When these conditions are met, the last 1MB of the SWAPPER.DAT file is deallocated leaving at least 528 KB of empty space available in case additional swapping needs to take place. Because of the need to meet all of these requirements and the time required to move the data around within the swap file, this process can take a long time. It does work, though. My swap file can be as large as 55 MB during a typical day. although I do observe some shrinkage of SWAPPER.DAT during the day, it usually remains over 40 MB until I quit for the evening. By the next morning, it is back down to 25 MB or so, which is just a little larger then the 20 MB default preallocation size I have specified in CONFIG.SYS.
This is very complex, but a large part of this strategy is to perform operations on the swap file in such a way that they affect the productive tasks as little as possible.
Tuning
See “Tuning the SWAPPER.DAT file” for details of tuning the swap file.
OS/2 Memory Management
Intel memory structure
The structure of memory in an Intel processor environment is a legacy of the design inherited from the original IBM PC back in 1981. The Intel 8088 processor used in the PC had a memory address range of 1 MB. At the time, 1 MB was many times the size of the address space provided in any other personal computer. This 1 MB address space was divided by the need to access memory using a segmented memory model into sixteen 64 KB segments. The lower ten of those segments, 640 KB, were provided as user memory to load an operating system and application programs. The remaining upper 384 KB was reserved for BIOS, video RAM, and future use.
In order to ensure backward compatibility for operating systems and programs with the early computers, all Intel based personal computers since have retained this memory structure. Even the 80×86 and Pentium class processors have an identical memory structure in the lower 1 MB. Above the 1 MB address, however, the address space is unbroken up to 4 GB and operating systems and applications can access all of it unencumbered – if the hardware will support that much memory.
It is important to understand that this memory structure is not a result of the design of the 80×86 class of processors; it is an artefact of the design of the original IBM PC.
Figure 1: Memory map of OS/2 in an Intel environment.
OS/2 memory usage
OS/2 Warp can access the entire 4 GB memory address space of the Intel 80×86 processor family. This includes the 80386, 80486, Pentium, Pentium Pro, and all the DX, SX and SLC variants of these processors. When Warp is loaded into RAM at boot time, the OS/2 kernel begins loading at the lower boundary of memory. It fills the lower 640 KB of RAM first, skips the 384 KB of reserved memory address space, and continues loading into the area beyond 1 MB. When OS/2 is running, it essentially ignores the address space between 640 KB and 1 MB
Once the kernel is loaded, the rest of memory is available for use by user application programs. These can be real OS/2 programs, DOS programs, and Windows 3.1 programs. Paged access to memory
Application programs do not access memory directly under OS/2. To ensure that application programs do not use memory which does not belong to them, memory can be accessed only through the operating system. This is accomplished through the use of page tables. Warp manages the page tables, and memory, with the support of the processor.
Under Warp, all memory is divided into fixed, non-movable blocks called Pages. Warp’s memory manager keeps track of memory usage with the Page Tables. Whenever a program is loaded by Warp, the memory manager creates a page table for that program. The page table is a list of memory pages which belong to the program. The Page table entries also contain information about how the memory is being used and is the basis for the memory protection mechanism of Warp.
Figure 2: OS/2 Warp accesses physical memory through the Page Table. The Page table entries also contain information about how the memory is being used and are the basis for the memory protection mechanism of Warp.
The most important thing to understand about memory management in OS/2 is not how physical address are generated; rather it is how each program’s virtual memory space is isolated from the rest of the programs. Each entry in the page table for a process contains an address pointer to the base location of the physical page of memory represented. It also contains attribute bits which describe how the physical memory is used and what access to the memory is permitted. The attribute bits which are important for this discussion are:
- Commit When this bit is on, the page of memory has been committed to physical storage, either RAM or fixed disk. The Commit and Decommit bits are mutually exclusive; only one can be on at a time, while the other must be off.
- Decommit When this bit is on, the memory page has been assigned to the program but, because the program has not yet stored any data in the page, or used it in any way, the page has not been committed to physical memory. In this way OS/2 only uses physical memory resource which is actually needed by a program. This is called sparse allocation. The Commit and Decommit bits are mutually exclusive; only one can be on at a time, while the other must be off.
- Execute This bit, when on, means that the data stored in the page is executable code.
- Read When on, this bit means that the data in the page is readable. If off, the data cannot be read.
- Write When this bit is on, it means that the page can be written to.
Access to any page in a manner which is inconsistent with its attributes causes the Intel processor to generate an access fault. OS/2 has a kernel level process, HARDERR.EXE, which handles these hardware errors from the processor. The hardware error handler determines the cause of the access violation and displays an error message for the user to see. In some cases, where the error occurs in the kernel of OS/2, an Internal Processing Error (IPE), is generated and the system is stopped.
Virtual Memory
OS/2 utilizes what is known as virtual memory. Virtual memory is provides a protected address space to each program running on the computer. From the viewpoint of the program, as shown in Figure 3, it resides alone in a computer address space which is contiguous and sequential. Because this memory space is protected, other programs cannot obtain access to it. Virtual memory can also use available hard drive space as auxiliary storage when the computer’s RAM is all in use. What this means is that when you have 24 MB of RAM in your system, and you are running programs which together require 37.5 MB of memory for executable code and data, you need an additional 13.5 MB of RAM which you don’t have. In OS/2 Warp, the memory manager uses available hard disk space to substitute for that unavailable RAM.
Figure 3: Each Application in a virtual memory system appears to have sequential, contiguous, and isolated memory space.
In fact, the physical memory resource allocated to each application may be neither sequential nor contiguous, and may not even be in RAM. Figure 4 shows that some pages of memory for a given program may be located in RAM, while other memory pages may be located on the fixed disk drive. It is OS/2, or rather OS/2′s memory manager which is responsible for mapping the virtual memory to physical memory resource. The OS/2 memory manager is also responsible for moving data from disk to RAM when they are needed for the computer to work on.
When physical RAM is filled up, and yet more RAM is needed by a program, the OS/2 memory manager transfers the contents of one or more pages of RAM into the SWAPPER.DAT file in the hard drive. Those pages of RAM are then allocated to the program which needs them. Entries for these memory pages are created in the page table for the program which needed them, and the entries show the location of the page in RAM.
When a program attempts to access a page of memory which has been swapped out to the hard drive, the processor generates a page fault and the OS/2 memory manager then retrieves the page from the hard drive and places it into RAM. If necessary to make room for this page transferred to RAM from the hard drive, the OS/2 memory manager will dispose of pages which have been marked as discardable, or will transfer pages from RAM to the hard disk.
Figure 4: OS/2 maps virtual memory to a physical resource, either RAM or fixed disk.
When any application, as a result of a programmer error or an overt attempt by the programmer, attempts to access memory which does not belong to that program, the Intel processor generates an access violation. The processor knows that the memory does not belong to the program trying to access it because there is no entry in the page table for that program for the memory in question. Warp’s error handler interprets this access violation as a Trap 000D error. When a program accesses memory which does not belong to it, the only option which OS/2 allows the user is to terminate the errant program. See Figure 1 in the document “OS/2 Crash Protection” for an example of a program which can crash with a Trap 000D error because it attempts to access memory which does not belong to it.
For any kind of problem with a program which creates an access violation, the error handler first displays a SYS3175 error. To determine the specific problem, click on the button to see the registers. At that point the specific trap error is displayed.
Ring Protection mechanism
OS/2 uses a four level protection mechanism to protect itself, the operating system from interference by other programs. This is not the same as the memory protection, actually memory isolation, which isolates programs’ memory spaces from each other. This ring protection mechanism, diagrammed in Figure 1, is used to ensure that applications cannot alter registers in the CPU or manipulate memory directly by accessing the page tables. The protection mechanism prevents this by refusing requests from programs other than a kernel level process to use the CPU instructions required to access the CPU registers and the page tables. The ring protection mechanism gets its name from the concentric rings used to diagram it.
The ring levels
OS/2 runs at ring level 0 which is the highest level of protection. Actually only the kernel of OS/2 and certain other kernel level functions run at this level. This is the most protected level of the CPU and is used only by an operating system. Running at ring 0 gives the operating system access to the privileged CPU instructions which are used to manipulate the CPU registers and the page tables. Access to these privileged instructions allows OS/2 to manage memory and to manage the operation of the CPU and the computer as a whole. It is important to note that the operating system, because it runs at ring 0, can use all of the CPU instructions available to the outer rings as well as those limited to programs running at ring 3.
Ring level 1 not used is not used in OS/2. This was a simple design decision on the part of the OS/2 architects who felt that providing access to this level would not offer any significant advantages to the operating system structure while adding unnecessary complexity. The kernel running at ring 0 can use any of the few instructions provided by this level.
Applications normally run at ring level 3. This is the least protected level, and programs which run at this level are the least trusted. That is, they are to be prevented from manipulating the hardware directly under any circumstances. In most cases, however, it is not necessary for applications to use hardware directly. The device driver structure of OS/2 provides program independent methods for accessing all hardware and so application programs normally have no need to do so.
IOPL
IOPL (I/O Privilege Level) programs run at ring 2. Ring 2 gives some few programs which need it a little more direct access to the hardware of the computer than they can have at ring 3. The sensitive instructions of ring 2 can be used by application programs to use instructions which exercise a little more control over parts of the computer like serial or parallel ports. Even with this additional level of access, however, OS/2 rigidly supervises the program using IOPL.
Any program which requires access to IOPL must first tell OS/2 that it will access ring 2. The programmer’s API which is used for IOPL at ring 2 is tightly controlled by OS/2 to prevent applications from causing problems. Unfortunately, a program written to access I/O Privilege Level can take complete control of a device; this cannot happen at ring 3. If the program does not relinquish control of the device, other programs which need access to the device, including the operating system, may appear to lock up while they wait for access to be granted. Until the program running at ring 2 relinquishes the device, all other programs must wait. It is imperative, therefore, that programmers working with IOPL at ring 2 follow IBM guidelines about programming at that level and release the device as soon as possible.
The statement IOPL=YES is required in the CONFIG.SYS file to allow programs to access ring 2 IOPL level instructions. If this statement has been altered such that a particular program which requires IOPL cannot get access to it, an error is displayed which says, “The system is not configured to support this program.”
IOPL=YES Allows I/O Privilege Level access to be granted to all programs which require it Protect ring level 2.
IOPL=<list> Allows I/O Privilege Level access to be granted to only those programs in the list. All other programs will be refused access to IOPL. The list consists of the names of executable files separated by commas.
Dynamic Link Libraries – DLL
OS/2 uses libraries of executable code call Dynamic Link Libraries, or DLLs. DLLs are used to improve the performance of OS/2 and application programs and to reduce the amount of disk space and RAM required to store and run programs.
Dynamic linking means that the DLLs are linked to the EXE code at load time or at run time rather than when the program is linked by the programmer. Static linking places all of the runtime code into a single large executable module which must be loaded into RAM in its entirety. Because many DLLs are designed to be loaded into RAM only when they are called by a program, this can make load time faster so that programs begin to run faster.
DLLs can be used by many programs rather than just one. Since many functions residing in a DLL are needed by many executable programs, a single DLL can take the place of static linking the same code multiple times into multiple executable files. This saves disk space and RAM because a single instance of a DLL in RAM can be used by multiple programs.
Dynamic linking can be accomplished in two ways under OS/2.
- Load-time dynamic linking loads DLLs called from within a code segment at the time the segment is loaded into memory. This causes load time to be longer but can result in improved run-time performance, especially if the DLL is used frequently.
- Run-time dynamic linking postpones loading the DLL until the code actually calls a function in the DLL. This reduces the time required to initially load the program and get it running, and also results in a smaller RAM footprint. This is appropriate for DLLs which are infrequently used because it can impact performance slightly as DLLs are loaded during execution of programs.
Symmetric MultiProcessing (SMP)
Warp Server SMP
Symmetric MultiProcessing is used to increase the processing capability of a single computer. By using multiple processors the amount of work which can be performed by a single computer can be increased considerably. Warp Server SMP supports SMP computers with from one to sixty four processors and provides a significant improvement in performance over computers with a single processor.
Warp Server SMP and Warp Server for e-business are both scaleable up to 64 processors in a single computer. Warp Server is optimized for 4 processors and Warp Server for e-business is optimized for 8 processors.
Under Warp Server SMP and Warp Server for e-business, Symetric MultiProcessing spreads all of the computing tasks among all of the processors in the computer as evenly as possible, so that each processor has some of the load.
Windows NT Comparison
Windows NT, in contrast to the way Warp Server SMP works, loads up each processor completely before placing any load on the additional processors which may be available. This causes some processors to do most of the work, while other processors may not do anything at all.
Windows NT is, theoretically, capable of scaling up to 16 processors, but in reality, it can only use a maximum of 4 processors effectively. Even then, based on independent third party tests, Warp Server on a single processor computer outperforms Windows NT on a 4 processor SMP environment.