Locus, V, Mach: Difference between revisions

From Soma-notes
← Older edit
Rgould (talk | contribs)
9 edits
No edit summary
Rgould (talk | contribs)
9 edits
Add notes for Yuri
 
(2 intermediate revisions by one other user not shown)
Line 11: Line 11:


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 [http://en.wikipedia.org/wiki/Mach_kernel Wikipedia's article on Mach].
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 [http://en.wikipedia.org/wiki/Mach_kernel Wikipedia's article on Mach].
==Debate==
Debate about the pros and cons of RPC. Topic: RPCs are the right foundation for the distributed applications (on today's Internet).
===Pros===
# Easy to use
#* makes remove procedure calls look like local calls
#* local is easy
#* therefore remove is easy with RPC - good!
# (Counter to first con) Use standards, problem goes away
# Easy to debug
# Avoids complexity of protocol design
# RPC can be abstracted from the protocol design
# (Counter to fourth con) Use threads for interactivity. Manage complexity by doing things pairwise.
# (Counter to fifth con) - wrong!
# (Counter to seventh con) - Use standards (ORBs in CORBA, etc.) for authentication
# (Counter to eighth con) - But you specify the API
# (Counter to ninth con) - It's the same with other methods. But RPC makes it easier to do.
===Cons===
# Language/implementation specific
# (Counter to third pro) Not easy to debug. example: NullPointerException thrown on server, containing line of erroneous code running on the server.
# Counter to fifth pro) But there is more overhead - slower
# Synchronous - wrong model for large, distributed applications, and also bad for users
# Limited scalability - hard to do well
# Limited control of communication details
# Authentication is opaque
# Larger attack surface area
# Poor match to listening (hard for server to communicate information back to client)
# Backwards compatibility is difficult
# RPC is not a "natural" interaction style - message passing is more similar to human communication
# Too much to set up for simple applications
# Less flexible
===Comments===
RPC makes the simple things easy, but the most difficult aspects are still prevalent. Good to use if you are only using the common case. For example, a cluster that is isolated from the Internet.


==Questions to be discussed==
==Questions to be discussed==
Line 57: Line 21:
# To what extent does their design work in the context of the modern Internet?  Discuss wins and limitations.
# To what extent does their design work in the context of the modern Internet?  Discuss wins and limitations.
# What concepts from the paper have been adopted by today's systems?  What concepts should be adopted?  What should be ignored?
# 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

Latest revision as of 18:25, 2 February 2008

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
Retrieved from "https://homeostasis.scs.carleton.ca/wiki/index.php?title=Locus,_V,_Mach&oldid=1751"