Operating Systems: A Spiral Approach
Format: PDF / Kindle (mobi) / ePub
Elmasri, Levine, and Carrick's "spiral approach" to teaching operating systems develops student understanding of various OS components early on and helps students approach the more difficult aspects of operating systems with confidence. While operating systems have changed dramatically over the years, most OS books use a linear approach that covers each individual OS component in depth, which is difficult for students to follow and requires instructors to constantly put materials in context.
Elmasri, Levine, and Carrick do things differently by following an integrative or "spiral" approach to explaining operating systems. The spiral approach alleviates the need for an instructor to "jump ahead" when explaining processes by helping students "completely" understand a simple, working, functional system as a whole in the very beginning. This is more effective pedagogically, and it inspires students to continue exploring more advanced concepts with confidence.
machine than it would be to buy a bigger system that could do the entire task itself. If the system will need to service a large number of users it might not be possible to service them all with a single system. Scaling. When we first develop an application we do not necessarily know how big the system load will get. What we think of as a small service might become an overnight sensation and require that it serve many more users than we originally thought it would. A good example is the Google™
we could develop a system to do this function as cheaply as buying the service unless we have a very high volume of transactions to process. Components in multiple systems. We might be building a number of different systems that do similar jobs. Rather than build similar parts of many systems and be required to maintain them separately, we can build the common components to run as a separate process and have the various systems feed transactions to the common components. For example, these days a
with other level n modules, in addition to lower-level modules. Because of the difficulty of separating complex OS functionality into multiple layers, usually elm49810_ch02_019-044.indd 33 12/10/08 9:27:37 PM Confirming Pages 34 Part 1 Operating Systems Overview and Background FIGURE 2.4 Layered model of an Operating System. Shell (Command Interpreter) Utilities User Programs (browsers, games, word processing) API Memory Management Processor Scheduling File System Kernel Device
See Figure 5.1. The desktop had a trash can icon that could be used to delete items by dragging and dropping them on the icon. These are all metaphors and features we take for granted today, but they were fairly revolutionary for the time. Unlike the Palm OS, the OS design assumed that the screen was large enough to hold more than one window or to show the desktop with a window that did not take up the entire screen. The screens were only black and white and only had a resolution of 520 ϫ 342
intervals and making a mark everywhere the instruction counter has been in that interval. We might end up with something like Figure 8.3. We could instead imagine that we unwound a thread and placed it on the graph instead of marking the space with a pencil. This is an analogy that gave rise to the phrase “thread of execution.” Now suppose that we stopped this process, and saved all the data that represented the CPU state in a table (we might call it a thread control block, or TCB). Then further