Since the kernel is the prototypical protected subsystem, and was the natural starting place for design of Multics rings, I wanted to make sure that everyone understood the mechanics of how that worked.
In my CS537 (undergrad OS course) lecture notes, I have a nice section on how processes enter and exit the kernel in a modern operating system. This is material that typically does not appear in a text book. So check out this section of my notes:
http://pages.cs.wisc.edu/~bart/537/lecturenotes/enterexit.html
This should help as background to our class discussion on Friday.
If anyone is confused about multiple processes accessing the same segment at a time, our discussion group was as well. On page 159, "A single segment may be part of several virtual memories at the same time, allowing straightforward sharing of segments among users." This was troubling because after taking some kind of intro to OS course, I thought that processes don't generally share memory to communicate. Well, it turns out Multics is weird, and does grant multiple processes access to the same piece of physical memory via a segment, partly because Multics, "implemented a single level store for data access, discarding the clear distinction between files (called segments in Multics) and process memory" (as per Wikipedia).
ReplyDeleteThe take-away here is that reading the Wikipedia page on Multics was probably something I should have done before reading the paper and being all confused for contextual reasons (...among others). Take a look!
I think segments can be shared between address spaces like those includes codes. Thus an access control mechanism (like protection ring in this paper) is required to support this kind of segment sharing.
DeleteSharing segments between processes, or at least sharing member between process is very very common features in operating systems. Functions like mmap and shmget/shmat provide this feature in UNIX-like systems.
ReplyDeleteThe equivalent of mmap in Windows is CreateFileMapping.