Distributed operating system: Difference between revisions

Content deleted Content added
JLSjr (talk | contribs)
No edit summary
No edit summary
Line 181:
 
 
 
==== Aboriginal Distributed ConputerComputer Science ====
'''The DYSEAC'''<ref>Leiner, A. L. 1954. System Specifications for the DYSEAC. J. ACM 1, 2 (Apr. 1954), 57-81.</ref>
 
One of the first solutions to these new questions was the [[DYSEAC]], a self-described general-purpose [[Synchronization (computer science)|synchronous]] computer; but at this point in history, exhibited signs of being much more than general-purpose. In one of the earliest publications of the [[ACM]], in April of 1954, a researcher at the [[National Bureau of Standards]] – now the National [[nist|Institute of Standards and Technology]] ([[nist|NIST]]) – presented a detailed implementation design specification of the DYSEAC. Without carefully reading the entire specification, one could be misled by summary language in the papers high-level introduction, as to the true nature of this machine. The initial section of the introduction advises that major emphasis will be focused upon the requirements of the intended applications, and these applications would require flexible communication. However, with language suggesting the external devices mightcould be typewriters, [[Magnetic storage|magnetic medium]], and [[Cathode ray tube|CRTs]], and with the term “[[Input/output|input-output operation]]” used more than once, could quickly limit any paradigm of this system to a complex centralized “ensemble.” Seemingly, saving the best for last, the author eventually getsdescribes closerthe to thetrue nature of the system.
 
{{quote|Finally, the external devices could even include other full-scale computers employing the same digital language as the DYSEAC. For example, the SEAC or other computers similar to it could be harnessed to the DYSEAC and by use of coordinated programs could be made to work together in mutual cooperation on a common task… Consequently[,] the computer can be used to coordinate the diverse activities of all the external devices into an effective ensemble operation.|ALAN L. LEINER|''System Specifications for the DYSEAC''}}
 
While this more detailed description moveselevates the perception of the system up a notch or two, the best that can be distilled from this is some semblance of decentralized control. The avid reader, that would perseverepersevering in the investigation would get to a point whereat which the real nature of the system is divulged.
 
{{quote|Each member of such an interconnected group of separate computers is free at any time to initiate and dispatch special control orders to any of its partners in the system. As a consequence, the supervisory control over the common task may initially be loosely distributed throughout the system and then temporarily concentrated in one computer, or even passed rapidly from one machine to the other as the need arises. …it should be noted that the various interruption facilities which have been described are based on mutual cooperation between the computer and the external devices subsidiary to it, and do not reflect merely a simple master-slave relationship.|ALAN L. LEINER|''System Specifications for the DYSEAC''}}
 
ThereThis youis have it. Oneone of the earliest examples of a computer with capacity for distributed operation. Given the system and its distributed operating system potential is primitive – almost ethereal at points – this was a [[Supercomputer|super-computer]] in its daycontrol. [[United States Department of the Army|Dept. of the Army]] reports<ref>Martin H. Weik, "A Third Survey of Domestic Electronic Digital Computing Systems," Ballistic Research Laboratories Report No. 1115, pg. 234-5, Aberdeen Proving Ground, Maryland, March 1961</ref> show it was certified reliable and passed all acceptance tests in April of 1954. It was completed and delivered on time, in May of 1954. In addition, was it mentioned that this was a [[portable computer]]? It was housed in [[Tractor-trailer#Types_of_trailers|tractor-trailer]], and had 2 attendant vehicles and [[Refrigerator truck|6 tons of refrigeration]] capacity.
 
 
 
==== ProcessMulti-programming abstraction ====
'''The Lincoln TX-2'''<ref>Forgie, J. W. 1957. The Lincoln TX-2 input-output system. In Papers Presented At the February 26-28, 1957, Western Joint Computer Conference: Techniques For Reliability (Los Angeles, California, February 26 - 28, 1957). IRE-AIEE-ACM '57 (Western). ACM, New York, NY, 156-160.</ref>
 
Described as an input-output system of experimental nature, the Lincoln TX-2 placed a premium on flexibility in its association of simultaneously operational input-output devices. The design of the TX-2 was modular, supporting a high degree of modification and expansion, as well as flexibility in operating and programming of its devices. The system employed The Multiple-Sequence Program Technique.
 
This technique allowed for multiple program counters to each associate with one of 32 possible sequences of program code. These explicitly prioritized sequences could be interleaved and executed concurrently, affecting not only the computation in process, but also the control flow of sequences and switching of devices as well. Much discussion ensues related to the complexity and sophistication in the sequence capabilities of devices.
 
Similar to the previous system, the TX-2 discussion has a distinct decentralized theme until it is revealed that efficiencies in system operation are gained when separate programmed devices are operated simultaneously. It is also stated that the full power of the central unit can be utilized by any device; and it may be used for as long as the device's situation requires. In this, we see the TX-2 as another example of a system exhibiting distributed control, its central unit not having dedicated control.
 
 
Line 204 ⟶ 214:
 
The association of an address with a quantity of information is very much the result of the type of computer organization we now have. Writing a program in machine language, one rarely deals with the quantities of information themselves. A programmer normally must know where these quantities of information are located. He then manipulates their addresses according to the problem at hand. An address in this way often assumes the role of the name of a piece of information...
 
 
 
 
==== Process abstraction ====
'''The Structure of the "THE"-Multiprogramming'''<ref>Dijkstra, E. W. 1968. The structure of the “THE”-multiprogramming system. Commun. ACM 11, 5 (May. 1968), 341-346.</ref> (1968)
 
A multiprogramming system is described in which all activities are divided over a number of sequential processes. These sequential processes are placed at various hierarchical levels, in each of which one or more independent abstractions have been implemented. The hierarchical structure proved to be vital for the verification of the logical soundness of the design and the correctness of its implementation.