| | | Secondary Storage |
To hold the collection of subroutines, as well as global data and parameters which consist of large volumes of data a linuar virtual memory space is used. The secondary storage to hold the virtual memory is conventional RAM built into the computer. The algorithms used to allocate and assign memory without conflicts and race conditions are well known from the theory and practice of operating systems and are not discussed here. The virtual memory allows as to broaden the range of algorithms that can be executed by relaxing the restrictions of the former section: Instead of passing parameters literally and whole sections of replicated code, pointers to them can be packaged into the quants. If a CPU absorbs a quant, it has to fetch the block of code from virtual memory and located in the secondary storage. While this can result an sending forth and back several messages through the grid to the CPU's concerned with I/O, there is always a chance that the required code is already present in another node in the message path, and can be either fetched directly from there. It can also be decided to execute the quant in that node if it is available.
The virtual memory should be designed sufficiently large to accommodate all information ever needed. A fourty bit address space, for example could address more then ten terrabyte, which should suffice to hold most programs and data people need for day to day use. To simplify access to secondary storage it is perceived as paged memory, which is partially cached in conventional RAM-chips and periodically swapped/backed up to harddisks.
If a conventional filesystem is required it is advisable to store it on a simulated RAM-disk in the virtual memory, however we assume that this complication is not required. One function of the required meta-operating system would be to guarantee that the grids state in local and conventional memory is completly saved to disk, and restored on power up, so all data processing can be done in memory.
| | | Secondary Storage |