The Swapping Process
Before discussing additional applications of common variables, it is useful to describe the “swapping” process by which a single computer can appear to interact with hundreds of students simultaneously. The computer actually handles students one at a time but processes one student and shifts to another so rapidly that the students seem to be serviced simultaneously. In order to process a student, the student's lesson and individual status (including the variables v1 through v150) must be brought into the “central memory” of the computer. After a few thousandths of a second of processing, the student's modified status is transferred out of the central memory (to be used again at a later time) and another student's lesson and status are transferred into central memory. This process of transferring back and forth is called “swapping,” and the large storage area where the lessons and status banks are held is called the “swapping memory.” The swapping memory must be large enough to hold all the status banks and lessons which are in active use; that is, in use by students presently working at terminals. It is not necessary for the swapping memory to also hold the many lessons not presently in use nor the status banks for the many students not using the computer at that time. These inactive lessons and status banks are kept in a still larger “permanent storage” area. (See Fig. 11-1.)
When a student sits down at a terminal and identifies herself as “Jane Jones” registered in “french2a”, her status bank is fetched from permanent storage to see what lesson she was working on and where in the lesson she left off last time. If the lesson is already in the swapping memory (due to active use by other students), Jane Jones is simply connected up to that lesson, and, as she works through the lesson, her lesson and her changing status bank will be continually swapped to central memory. If, on the other hand, the required lesson is not presently in active use, it must be moved from permanent storage to the swapping memory. (This involves a translation of the TUTOR statements into a form which the computer can process later at high speed.) This fetching of the inactive lesson from permanent storage to prepare an active version in the swapping memory will typically be done once in a half-hour or more often as the student moves from one lesson to another. In contrast, the swapping of the active lesson to central memory happens every few seconds as the student interacts with the lesson. Therefore, the swapping transfer rate must be very high (whereas a low transfer rate between permanent storage and the swapping memory is adequate).
When Jane Jones leaves for the day, her status bank is transferred from the swapping memory to permanent storage. This makes it possible for her to come back the next day and restart where she left off.
The question arises as to why there are three different memories: central memory, swapping memory, and permanent storage. For example, why not keep everything in the central memory where students can be processed? It turns out that central memory is extremely expensive, but permanent storage in the form of rotating magnetic disks is very cheap. Why not do swapping directly between permanent storage and central memory? The rate at which lessons can be fetched from permanent storage is much too slow to keep the computer busy: the computer would handle only a small number of students because a lot of time would be wasted waiting for one student to be swapped for another. If the cost of the computer were shared by a small number of students, the cost would be prohibitively high. In order to boost the productivity of the computer, a special swapping memory is used which permits rapid swapping. This minimizes unproductive waiting time and raises the number of students that can be handled. The swapping memory is cheaper than central memory but considerably more expensive than permanent storage.
There is, therefore, a hierarchy of memories forced on us by economic and technological constraints. The expensive, small central memory is the place where actual processing occurs, and there is never more than one student in the central memory. Material is swapped back and forth to a large medium-cost swapping memory whose most important feature is a very high transfer rate to central memory. Permanent storage is an even larger and cheaper medium for holding the entire set of lessons and student status banks. It has a low transfer rate to the swapping memory.
Common Variables and the Swapping Process
Now it is possible to describe more precisely the effect of a -commonstatement in a lesson. Just as an individual student's lesson and status bank (including the student variables vl through v150) are swapped between central memory and the swapping memory, so a set of common variables associated with the lesson is swapped between central memory and the swapping memory. There is in central memory an array of 1500 variables, called vc1 through vc1500, into and out of which a set of common variables is swapped. As long as the -common- statement specifies a set of no more than 1500 common variables, this set will automatically swap into and out of the central memory array vel to vc1500. (Sec Fig. 11-2.) (There is a -comload- command which can be used to specify which portions of a common to swap if the common contains more than the 1500 variables which will fit into central memory.) All 1%0 variables in the central memory array are set to zero before bringing a lesson, status bank, and common into central memory, so that any of these variables not loaded by the common will be zero.
Note that the student status banks and commons are swapped in and out of central memory in order to retain any changes made during the processing in central memory. On the other hand, lessons are brought into central memory but are not sent back since no changes are made to the lesson. (A lesson only has to be copied into but not out of central memory.) The separation of the modifiable status banks and commons from the unchanging lessons makes it possible for a single copy of a lesson to serve many students.
It is dangerous to use vc-variables without a -common- statement or to use vc-variables outside the range loaded by the common (e.g., referring to vc3 when there is a “common 2” statement in the lesson). For example, consider this sequence in a lesson which has no -common- statement:
This will show 0, not 18.34. The “pause 2” statement causes this student's material to be swapped out to the swapping memory for two seconds while many other students are processed. When the student is swapped back into central memory, all the ye-variables are zeroed. As a matter of fact, vc735 may temporarily take on many different values during those two seconds as different students are processed. On the other hand, a “common 800” would insure that vcl through vc800 would be saved in the swapping memory and restored after two seconds, so that the “18.34” stored in vc735 would again be available to be shown (unless it had been changed by a student using the same common who was processed during the two-second wait). Similarly, because the student variables vl through v150 are part of the swapped student status bank, the sequence:
will correctly show “3.72”. The contents of the student variables cannot get lost in the swapping process because these variables are saved in the swapping memory and restored to central memory the next time this student is processed.
The fact that common variables are shared by all students studying the lesson is extremely useful but can cause difficulties if you are not careful. Suppose you want to add up the square roots of the absolute values of vc101 through vc1000:
This iterative calculation will take longer than one “time-slice” (the computing time TUTOR gives you before interrupting your processing to service other students). You are swapped out and will be swapped back into central memory later to continue the computation. It might take several time-slices to complete the computation, and in between your time-slices other students are processed. This time-slicing mechanism insures that no one student can monopolize the computer and deny service to others. Suppose two students, Jack and Jill, are studying this lesson and sharing its common. Suppose that Jack has reached the part of the lesson that contains the -doto- shown above. If, at the same time, Jill runs through calculations that modify vc101 through vc1000, her modifications will be made during the interruptions in Jack's processing. The total that Jack calculates will, therefore, be based on changing values and will not be the total at a particular instant. Jack calculates a partial total, Jill makes some changes, Jack continues to do more calculations in the -doto-, then Jill makes further changes, etc. At the end Jack has a peculiar total made up of partial totals made at different times. Even more drastic things will happen if “total” is itself a common variable: Jill might do “total⇐0” right in the middle of Jack's summation!
If it is necessary to get an accurate total at a specific instant, it is necessary to lock out Jill and other students from modifying common until the totaling is complete. This is done by doing a “reserve common” statement before starting Jack's calculation and a “release common” statement after the calculation is complete. The -reserve- command checks to make sure no other student has reserved the common, and then reserves the common. The system variable “zreturn” is set to -1 if the -reserve- was able to get control of the common. Otherwise “zreturn” is set to the station number of the student who had previously reserved the common. Normally, if you can't get the common, you loop waiting for the other person to do a “release common”:
Notice that you must reserve and release common for Jill as well as for Jack (doing it for one but not the other will not prevent the other from looking at or changing the common).
Don't forget the “release common” for a student, or other students will get hung up waiting for the common to be available. When a student who has reserved a common signs out of the lesson, TUTOR automatically releases the common.
Note that a lock is certainly needed if different students are storing information into the same area of common. There is often no problem with having different students reading information out of the same area of common and no problem when storing information in different areas of common. Logical conflicts are most serious when modifying the same part of common. However, even in this case there are usually no problems. In the example of counting the number of students in the lesson, we simply execute “vc=vc1+ 1”, which cannot cause any problems since all of the modifications are completed in one simple step. (Note, however, that a very complicated -talc- statement, particularly one involving multi-element array operations, may take more than one time-slice to be performed.)