Content deleted Content added
No edit summary |
No edit summary |
||
Line 1:
{{Userspace draft|source=ArticleWizard|date=March 2010}}
<br /><br />
{{notice|
<big>'''''There are several improvements in (Daily) process'''''</big>
<br />{{pad|2em}} '''Some reference material supporting the parts of the structure have been entered'''
<br />{{pad|4em}} The snippets of text under each reference is a snippet of the reference itself, to display applicability
<br />{{pad|2em}} '''References are there to indicate from where the material for the given section will be derived'''
<br />{{pad|4em}} The reference itself will most likely NOT be directly included in the given section's displayed text
<br />{{pad|2em}} '''There are no sections complete at this moment'''
<br />{{pad|4em}} All sections will be receiving much attention in the coming days
<br />{{pad|4em}} Therefore, completeness of a given sections information is not in question
<br />{{pad|4em}} The propriety, continuity, and applicability of the information is
<br />{{pad|2em}} '''All comments, observations, hints, corrections, additions, etc... are very welcome'''
}}<br />
<br /><br />
Line 16 ⟶ 24:
=== Transparency ===
{{pad|2em}}Common execution paradigm across multiple distributed entities
<br />{{pad|2em}}Complexity involves:
<br />{{pad|4em}}asynchronous communication
<br />{{pad|4em}}non-uniform memory access
<br />{{pad|4em}}probability of faults
<br />{{pad|4em}}possibility of heterogeneous remote resources
<br />{{pad|2em}}Distributed operating system must be able to isolate users from complexities
<br />{{pad|2em}}Provide a complete and consistent abstraction of resources, across the distributed system
<br />
<br /
=== Modularity ===
{{pad|2em}}System abstraction composed from modular subcomponents/entities
<br />{{pad|2em}}Entities usually smaller, functionally-cohesive, cooperative, and stateful
<br />
<br /
=== Persistence of Entity state ===
{{pad|2em}}existance not time-bound, regardless of breaks in system functions continuously
<br />{{pad|2em}}resides in nonvolatile storage; synchronized with current, stable, active copy
<br />{{pad|2em}}Subject to consistent and timely updates
<br />{{pad|2em}}Able to survive hardware failure
<br />
<br /
=== Efficiency ===
{{pad|2em}}Many issues can adversly affect system performance:
<br />{{pad|2em}}latency in interactions among distributed entities
<br />{{pad|4em}}local response facade requires remote entities' state be cached locally
<br />{{pad|4em}}and consistently synchronized to maintain the paradigm
<br />{{pad|2em}}Workload variations, delays, interruptions, faults, and/or crashes of entities
<br />{{pad|4em}}Distributed processing community assists when needed
<br />
<br /
=== Replication ===
{{pad|2em}}Duplication of state among selected distributed entities, and the synchronization of that state
<br />{{pad|2em}}Remote communication required to effect synchronization
<br />
<br /
=== Reliability ===
{{pad|2em}}Inherent redundancy across the distributed entities provides fault-tolerance
<br />
<br />
=== Flexibility ===
{{pad|2em}}OS has lattitude in degree of exposure to externals
<br />{{pad|4em}}Coordination of process activity
<br />{{pad|4em}}Where run; Near user?, resources?, avail. CPU?, etc...
<br />
<br /
=== Scalability ===
{{pad|2em}}node expansion
<br />{{pad|2em}}process migration
<br />
<br /
== History ==
Line 83:
==== Connectivity abstraction ====
'''Ethernet: distributed packet switching for local computer networks'''<ref>Metcalfe, R. M. and Boggs, D. R. 1976. Ethernet: distributed packet switching for local computer networks. Commun. ACM 19, 7 (Jul. 1976), 395-404.</ref>
==== Memory access abstraction ====
'''Intercommunicating Cells, Basis for a Distributed Logic Computer'''<ref>Lee, C. Y. 1962. Intercommunicating cells, basis for a distributed logic computer. In Proceedings of the December 4-6, 1962, Fall Joint Computer Conference (Philadelphia, Pennsylvania, December 04 - 06, 1962). AFIPS '62 (Fall).</ref> (1962)
The purpose of this paper is to describe an information storage and retrieval system in which logic is distributed throughout the system. The system is made up of cells. Each cell is a small finite state machine which can communicate with its neighboring cells ... The motivation stems from our contention that in the present generation of machines the scheme of locating a quantity of information by its "address" is fundamentally a weak one...
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
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.
==== Component abstraction ====
'''HYDRA:The Kernel of a Multiprocessor Operating System'''<ref>Wulf, W., Cohen, E., Corwin, W., Jones, A., Levin, R., Pierson, C., and Pollack, F. 1974. HYDRA: the kernel of a multiprocessor operating system. Commun. ACM 17, 6 (Jun. 1974), 337-345.</ref> (1974)
<br />
The design philosophy of HYDRA ... suggest that, at the heart of the system, one should build a collection of facilities of "universal applicability" and "absolute reliability" -- a set of mechanisms from which an arbitrary set of operating system facilities and policies can be conveniently, flexibly, efficiently, and reliably constructed.
Line 109 ⟶ 113:
Defining a kernel with all the attributes given above is difficult, and perhaps impractical... It is, nevertheless, the approach taken in the HYDRA system. Although we make no claim either that the set of facilities provided by the HYDRA kernel ... we do believe the set provides primitives which are both necessary and adequate for the construction of a large and interesting class of operating environments. It is our view that the set of functions provided by HYDRA will enable the user of C.mmp to create his own operating environment without being confined to predetermined command and file systems, execution scenarios, resource allocation policies, etc.
<br />
==== Initial composition ====
'''The National Software Works: A Distributed Processing System'''<ref>Millstein, R. E. 1977. The National Software Works: A distributed processing system. In Proceedings of the 1977 Annual Conference ACM '77. ACM, New York, NY, 44-52.</ref> (1975)
The National Software Works (NSW) is a significant new step in the development of distributed processing systems and computer networks. NSW is an ambitious project to link a set of geographically distributed and diverse hosts with an operating system which appears as a single entity to a prospective user.
==== Complete instantiation ====
'''The Rosco Distributed Operating System'''<ref>Solomon, M. H. and Finkel, R. A. 1979. The Roscoe distributed operating system. In Proceedings of the Seventh ACM Symposium on Operating Systems Principles (Pacific Grove, California, United States, December 10 - 12, 1979). SOSP '79.</ref> (1979)
Roscoe is an operating system implemented at the University of Wisconsin that allows a network of microcomputers to cooperate to provide a general-purpose computing facility. The goal of the Roscoe network is to provide a general-purpose computation resource in which individual resources such as files and processors are shared among processes and control is distributed in a non-hierarchical fashion. All processors are identical. Similarly, all processors run the same operating system kernel. However, they may differ in the peripheral units connected to them. No memory is shared between processors. All communication involves messages explicitly passed between physically connected processors. No assumptions are made about the topology of interconnection.
The decision not to use logical or physical sharing of memory for communication is influenced both by the constraints of currently available hardware and by our perception of cost bottlenecks likely to arise as the number of processors increases.
Line 131 ⟶ 140:
==== Coherent memory abstraction ====
==== File System abstraction ====
==== Transaction abstraction ====
<br />{{pad|4em}}'''Sagas'''<ref>Garcia-Molina, H. and Salem, K. 1987. Sagas. In Proceedings of the 1987 ACM SIGMOD international Conference on Management of Data (San Francisco, California, United States, May 27 - 29, 1987). U. Dayal, Ed. SIGMOD '87. ACM, New York, NY, 249-259.</ref>
{{pad|2em}}''Transactional Memory''
<br />{{pad|4em}}'''Composable memory transactions'''<ref>Harris, T., Marlow, S., Peyton-Jones, S., and Herlihy, M. 2005. Composable memory transactions. In Proceedings of the Tenth ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming (Chicago, IL, USA, June 15 - 17, 2005). PPoPP '05. ACM, New York, NY, 48-60.</ref>
<br />{{pad|4em}}'''Transactional memory: architectural support for lock-free data structures'''<ref>Herlihy, M. and Moss, J. E. 1993. Transactional memory: architectural support for lock-free data structures. In Proceedings of the 20th Annual international Symposium on Computer Architecture (San Diego, California, United States, May 16 - 19, 1993). ISCA '93. ACM, New York, NY, 289-300.</ref>
<br />{{pad|4em}}'''Software transactional memory for dynamic-sized data structures'''<ref>Herlihy, M., Luchangco, V., Moir, M., and Scherer, W. N. 2003. Software transactional memory for dynamic-sized data structures. In Proceedings of the Twenty-Second Annual Symposium on Principles of Distributed Computing (Boston, Massachusetts, July 13 - 16, 2003). PODC '03. ACM, New York, NY, 92-101.</ref>
<br />{{pad|4em}}'''Software transactional memory'''<ref>Shavit, N. and Touitou, D. 1995. Software transactional memory. In Proceedings of the Fourteenth Annual ACM Symposium on Principles of Distributed Computing (Ottowa, Ontario, Canada, August 20 - 23, 1995). PODC '95. ACM, New York, NY, 204-213.</ref>
==== Persistence abstraction ====
==== Coordinator abvstraction ====
==== Reliability abstraction ====
Line 176 ⟶ 198:
=== Current Research ===
==== replicated model extended to a component object model ====
Line 186 ⟶ 210:
=== Future Directions ===
==== System able to provide low-level complexity exposure, in proportion to trust and accepted responsibility ====
==== Infrastructure focus on multi-processor/core ====
==== System extends a consistent and stable impression of processing over extremes in heterogeneity ====
==== System able to provide effective, stable, and beneficial view of vastly inceased complexity on multiple levels ====
Line 209 ⟶ 240:
<!--- See http://en.wikipedia.org/wiki/Wikipedia:Footnotes on how to create references using <ref></ref> tags which will then appear here automatically -->
{{Reflist}}
== External links ==
| |||