Locus, V, Mach

From Soma-notes
Revision as of 14:25, 2 February 2008 by Rgould (talk | contribs) (Add notes for Yuri)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search

Readings

David R. Cheriton, "The V Distributed System."

Bruce Walker et al., "The LOCUS Distributed Operating System."

These two papers describe V and LOCUS, two early distributed operating systems.


Michael Young et al., "The Duality of Memory and Communication in the Implementation of a Multiprocessor Operating System."

This paper describes some key ideas behind Mach, a seminal microkernel-based operating system. The design of Mach informs later work in distributed operating systems. For more background on Mach, I suggest reading Wikipedia's article on Mach.

Questions to be discussed

  1. What did the (technical) world look like when this distributed OS was designed & implemented?
  2. What are the key design features of the OS? What are the key compromises?
  3. To what extent is their system a "distributed operating system"?
  4. What is the basic argument for their design choices? What evidence do they cite in their favor?
  5. To what extent do you "believe" their design choices were right? Why?
  6. To what extent does their design work in the context of the modern Internet? Discuss wins and limitations.
  7. What concepts from the paper have been adopted by today's systems? What concepts should be adopted? What should be ignored?

Debate about the OSes

Topic: Microsoft has more to learn from ______ rather than ______ or ______ because....

LOCUS

  • + error handling
  • + automatic file merging
  • - sync. hotspots
    • + fix by smart directory placement
  • + automatic backups
  • - not scalable

V

  • + standard protocols
    • - less profitable, no lock-in
  • + process migration
  • - slow -> context switches
  • + distributed processes

MACH

  • + microkernel -> fault tolerant
  • + user space OS extensions
  • + easy shared memory (memory obj)
  • - inefficient finding of resources (ports)
    • + use discovery service
      • + more secure
        • - port search
  • - slow -> context switches
  • + "real" production use