Disaster

Our attempt to provide a mapped address space required a lot of very complicated code, and it failed. The complicated code was most evident in the disk system, but also was evident in our complicated file structure and multi-level operations. We failed because we did not correctly simulate a mapped address space. The decision to simulate portions of disk files residing in ECS by ECS files led to structuring ECS files as a sequence of blocks, only some of which might exist. (If ECS files had been merely consecutive blocks of storage, they would have been much simpler.) Multi-level operations were supplied to permit an unsuccessful ECS file read or write action to automatically initiate a more expensive disk file action. This was the only place where multi-level operations were actually used. The major complications were in the disk system, which maintained complicated global tables recording which portions of which files were attached by which process. We were successful in our attempt to make ECS files appear to represent the ECS portions of disk files. However, the main intention in providing this facility was to make possible subprocess maps which pointed into disk files. The subprocess map facility failed, even at the simple level of maps into ECS files. This failure occurred under the following conditions:

i)

two subprocesses in the same process attempt to share some data by mapping into some common file, and

ii)

they both can be in CM simultaneously (one is a descendent of the other), and

iii)

at least one of them is permitted to modify the data.

Under these conditions, a subprocess has to explicitly read and write the common data in order to insure that his copy is correct. This totally defeats the purpose of the map. The reason for this failure is quite simple: the hardware did not provide address mapping. We attempted to simulate mapping by copying the mapped data into the appropriate regions of central memory. Thus, there could occur two independent copies in central memory of the same region of a file. This same problem can occur under other conditions:

a)

Two different regions in the same subprocess address space map to the same region in some file. Then a change in the data in one region will not be immediately reflected in the other.

b)

If the system were run on dual 6400's with a single ECS, and subprocesses in two different processes map into the same file. In this case, the problem can be prevented by a potentially very complicated mechanism which prevents the two subprocess from swapping into different CM's simultaneously. (We intended that our system might eventually run on the two 6400's owned by the computer center.)

c)

Two subprocess in the same process, one maps into a file, and the other attempts direct reads from the file. If one is a descendent of the other, the problem appears.  

d)

Same as c, except the subprocesses are in separate processes, but under a dual 6400 system.