Distributed operating system: Difference between revisions

Revision as of 05:44, 23 March 2010

Revision as of 06:09, 24 March 2010

Line 36:

|-

|style="background:#FDEE00;"|[[Image:Nuvola apps korganizer.svg|50px]]

|style="background:#DFFFFF;width:400px500px;"|'''Added rough draftdrafts of theTransparency secondand sectionModularity, ofunder "HistoryArchitectural features"...'''<br />&nbsp;&nbsp;&nbsp;[[User:JLSjr|JLSjr]] ([[User talk:JLSjr|talk]]) 0506:4409, 2324 March 2010 (UTC)

|}

{| class="wikitable" cellpadding="0" style="border:1.5px solid black;color:#000;margin-left:18em;"

|-

|style="background:#FDEE00;"|[[Image:Nuvola apps korganizer.svg|50px]]

|style="background:#DFFFFF;width:400px500px;"|'''Added rough draft of the firstsecond section of "History"...'''<br />&nbsp;&nbsp;&nbsp;[[User:JLSjr|JLSjr]] ([[User talk:JLSjr|talk]]) 05:3244, 1823 March 2010 (UTC)

|}

{| class="wikitable" cellpadding="0" style="border:1.5px solid black;color:#000;margin-left:18em;"

|-

|style="background:#FDEE00;"|[[Image:Nuvola apps korganizer.svg|50px]]

|style="background:#DFFFFF;width:400px500px;"|'''Added rough draft of "Overview"the first section of "History"...'''<br />&nbsp;&nbsp;&nbsp;[[User:JLSjr|JLSjr]] ([[User talk:JLSjr|talk]]) 0605:4532, 1718 March 2010 (UTC)

|}

{| class="wikitable" cellpadding="0" style="border:1.5px solid black;color:#000;margin-left:18em;"

|-

|style="background:#FDEE00;"|[[Image:Nuvola apps korganizer.svg|50px]]

|style="background:#DFFFFF;width:400px500px;"|'''Added rough draft of "LeadOverview" section...'''<br />&nbsp;&nbsp;&nbsp;[[User:JLSjr|JLSjr]] ([[User talk:JLSjr|talk]]) 0906:0245, 1617 March 2010 (UTC)

|}

{| class="wikitable" cellpadding="0" style="border:1.5px solid black;color:#000;margin-left:18em;"

|-

|style="background:#FDEE00;"|[[Image:Nuvola apps korganizer.svg|50px]]

|style="background:#DFFFFF;width:500px;"|'''Added rough draft of "Lead" section...'''<br />&nbsp;&nbsp;&nbsp;[[User:JLSjr|JLSjr]] ([[User talk:JLSjr|talk]]) 09:02, 16 March 2010 (UTC)

|}

{| class="wikitable" cellpadding="0" style="border:1.0px solid black;color:#000;margin-left:18em;"

|-

|style="background:#FDEE00;"|[[Image:Nuvola apps korganizer.svg|50px]]

|style="background:#DFFFFF;width:400px500px;"|'''Added "Introduction" outline; framework of text to come...'''<br />&nbsp;&nbsp;&nbsp;[[User:JLSjr|JLSjr]] ([[User talk:JLSjr|talk]]) 04:56, 15 March 2010 (UTC)

|}

{| class="wikitable" cellpadding="0" style="border:0.5px solid black;color:#000;margin-left:18em;"

|-

|style="background:#FDEE00;"|[[Image:Nuvola apps korganizer.svg|50px]]

|style="background:#DFFFFF;width:400px500px;"|'''Added initial entry...'''<br />&nbsp;&nbsp;&nbsp;[[User:JLSjr|JLSjr]] ([[User talk:JLSjr|talk]]) 12:48, 13 March 2010 (UTC)

|}

<br />

Line 125 ⟶ 130:

=== Transparency ===

{{pad|2em}}Common execution paradigm across multiple distributed entities

Transparency is the attribute of a distributed operating system allowing it to appear as a unified, centralized, and local operating system. Many factors lend complexity to the concept of transparency in a distributed operating system (a system). Elements of a system are distributed spatially; a system’s software, its processes, and data are also distributed among these elements. Occasionally, elements need to communicate with other distant elements in the system. When a process asks a question of another process, it should not stand idly waiting for the answer; it should continue working productively. However, it should also remain alert for the answer; and receive it and process it immediately, to maintain the illusion of local elements. This added level of complexity is asynchronous communication. Communication time can become indefinite, when an element's connectivity is compromised, or an element itself fails. Connectivity and failure issues affect communication, but system processing is affected as well.

<br />{{pad|2em}}Complexity involves:

<br />{{pad|4em}}asynchronous communication

To remain transparent, a system's elements may copy (replicate) portions of themselves onto collections of host elements. In times of need, a failed element's information can be retrieved from these host elements to continue processing, and eventually reconstitute the faulty element. This too is added complexity, and it does not end here. This replication of information throughout the system requires coordination, and therefore a coordinator. The coordinator oversees many aspects of a system's operation, unless that coordinator fails. In this event, some other element must be chosen and constituted a coordinator. This process adds complexity to the system. The complexity in the system can quickly add up, and these examples by no means sum to a total. Transparency envelope a system in an abstraction of extremely complex construction; but provide a user with a complete, consistent, and simplified local interface to hardware, devices, and resources. The various facets of a system contributing to this complexity are discussed individually, below.

<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

A distributed operating system is inherently modular by definition. However, a system's '''modularity''' speaks more to its composition and configuration, the rationale behind these, and ultimately their effectiveness. A system element could be composed of multiple layers of components. Each of these components might vary in granularity of subcomponent. These layers and component compositions would each have a coherent and rational configuration towards some purpose in the system. The purpose could be for a more simplified abstraction, raw communication efficiency, accommodating heterogeneous elements, processing parallelism and concurrency, or possibly to support an object-oriented programming paradigm. In any event, the scattered distribution of system elements is not random, but is most often the result of detailed design and careful planning.

<br />{{pad|2em}}Entities usually smaller, functionally-cohesive, cooperative, and stateful

<br />

<br />

Line 187 ⟶ 188:

==== Aboriginal Distributed Computer ScienceComputing ====

'''The DYSEAC'''<ref>Leiner, A. L. 1954. System Specifications for the DYSEAC. J. ACM 1, 2 (Apr. 1954), 57-81.</ref>