COMP 3430 Operating systems – chapter 2 reading notes
Winter 2022
About these reading notes
Chapter 2: Introduction to Operating Systems
Copyright By PowCoder代写 加微信 powcoder
VirtualizingtheCPU ………………………………… 2 Virtualizingmemory ………………………………… 3 Concurrency ……………………………………. 3 Persistence …………………………………….. 3 DesignGoals ……………………………………. 4 SomeHistory……………………………………. 4
Earlyoperatingsystems:justlibraries……………………… 4 Beyondlibraries:protection………………………….. 4 TheEraofMultiprogramming …………………………. 5 Themodernera………………………………… 5
COMP 3430 Operating systems – chapter 2 reading notes Winter 2022
About these reading notes
These are my own personal reading notes that I took (me, Franklin) as I read the textbook. I’m pro- viding these to you as an additional resource for you to use while you’re reading chapters from the textbook. These notes do not stand alone on their own — you might be able to get the idea of a chap- ter while reading these, but you’re definitely not going to get the chapter by reading these alone.
These notes are inconsistently all of the following:
• Mesummarizingpartsofthetext.
• Mecommentingonpartsofthetext.
• Measkingquestionstomyselfaboutthetext.
– …andsometimesansweringthosequestions.
The way that I would expect you to read or use these notes is to effectively permit me to be your in- ner monologue while you’re reading the textbook. As you’re reading chapters and sections within chapters, you can take a look at what I’ve written here to get an idea of how I’m thinking about this content.
Chapter 2: Introduction to Operating Systems
The very introductory paragraph summarizes how a CPU runs a program (abstractly), fetching instruc- tions, decoding instructions, executing instructions, memory access, etc. Describes the von Neumann model!
Really briefly introducing the responsibilities of an operating system, specifically about making it “easy” to run programs. It is in charge of making sure the system “operates correctly and efficiently”.
The OS is a resource manager, where the resources are things like CPU, memory, and disks.
Virtualizing the CPU
We start with a simple program that prints out a string repeatedly. They’ve added a call to their own code (a function called Spin(n)) that runs for 𝑛 seconds before returning (it blocks!). The idea here is that we want to be able to show (in a really dumb way) that one process runs one at a time.
The next example is running this program 4 times (sticking an & to run them in the background).
The thing that they’re trying to do here is convince you that each program “sees” 1 CPU. It doesn’t nec-
essarily know anything about the processor that it’s running on, in fact, it might be switching around
COMP 3430 Operating systems – chapter 2 reading notes Winter 2022
between processors without ever knowing it. This is a weird, kind of head-scratching turn of events! We usually think about this as “a system has 𝑛 CPUs and programs run on them”, but this is taking that idea and putting it backward: we run 𝑛 programs and each one has a CPU, the OS’s job is to make it seem to each program that it has a CPU available to it.
There’s a keyword here “policy”, applying it to the idea that there’s a policy that’s stated or evaluated to decide which program gets to run when there are multiple programs running.
Virtualizing memory
Basic description of what memory is, how we interact with it. “Memory is an array of bytes”, each byte has an address, we can read and write to and from different bytes in memory.
WAIT A MINUTE you might be saying to yourself when you’re looking at figure 2.4; both running pro- grams have the same addresses? (NOTE: this might not actually happen in practice… The authors call this out in footnote #5, referring to address-space randomization)
This little bit here is reinforcing the idea that each program, as far as it’s concerned, has access to the entirety of memory to itself. Sort of like each program has however much memory is installed in your system. The OS’s job is to help each running program work and think that way.
Concurrency
Figure 2.5 shows a program running with threads and gives a basic introduction to the idea of concur- rency.
We’re also here introduced to the problems with concurrency. The example they’re showing here is two threads incrementing a single, shared variable. They actually give a basic explanation of why this code doesn’t work the way you think it should when you increase the number of loop iterations (++ is an operation that takes 3 instructions, not 1).
Persistence
Justifying the need for persistence (RAM is volatile). Definition of a “file system”.
Persistence and permanent storage is different from virtualizing the CPU and memory in that … per-
manent storage isn’t virtualized.
DON’T LET THE AUTHORS OF THIS BOOK vi shame you.
They describe this idea in terms of even writing software. An editor writes out to a file, the compiler has access to the same file, the OS has access to the same set of files when it runs the program.
COMP 3430 Operating systems – chapter 2 reading notes Winter 2022
Figure 2.6 does some basic I/O at a layer below fopen, and the text specifically refers to these as “system calls”. This is how they justify calling the OS a “standard library”. That’s fair, but needs to be
distinct from the C standard library.
They use, but do not define, the words “Device driver”.
They then introduce the terms “journaling” and “copy-on-write” as things that an OS and file system do when writing files, but (rightly) defer that until the later chapters.
Design Goals
“Abstractions” is a design goal. This should be something that’s obvious to them! Hopefully! The idea is that we’re trying to take a bunch of stuff and ignore the details so that we don’t have to worry about them and can focus on the problem.
“Performance” is a design goal. The main idea here isn’t “make it fast” (though that’s definitely a side- effect), it’s more “minimize work”. An OS should provide the ability to do things like virtualization, but should not cost a lot.
“Protection” is a design goal. This is security. We want to not only virtualize memory and CPU for programs, but want to make sure that programs can’t break out of their own virtualized memory and CPU space. This is introduced with the keyword “isolation”.
“energy-efficiency” and “security” are also design goals, though security is (rightly) described as an extension to “protection”.
Some History
Early operating systems: just libraries
The “code” part of an OS was a library. The scheduler was a person! This was known as “batch” pro- cessing.
Beyond libraries: protection
This part is… weird, because it omits something that I think is important. Just before this, no OS code was resident and running, the machine booted directly into user code. But now the OS is an actual running program.
They also talk about mechanics here of system calls, specifically in terms of modes and hardware privilege levels.
COMP 3430 Operating systems – chapter 2 reading notes Winter 2022
The Era of Multiprogramming
Hooray, that’s us! Well, it’s closer to us. They talk about UNIX, and that an OS would load memory pro- grams into memory then share the resources by switching between them. It’s kinda what’s happening now.
The modern era
The main difference here is the physical size and cost of the machine. It’s now cost effective for one person to have a computer where before it was a business or university thing.
They go back to DOS, saying that the earliest PC operating systems “forgot” what was discovered and applied on the larger computers and mainframes, but realistically, I think this is more like they didn’t see it being an issue.
程序代写 CS代考 加微信: powcoder QQ: 1823890830 Email: powcoder@163.com