UCB-CS162-操作系统笔记-一-

UCB CS162 操作系统笔记（一）

P1：Lecture 1 What is an Operating System - RubatoTheEmber - BV1L541117gr

Okay， well， welcome everybody to 162。

I'm one of the lecturers this term and Anthony Joseph。

We'll hear from a little bit later is also one。 And it's unfortunate that we have to start off the term virtually。

But I guess that's the way it is。 So we will become a in person as soon as we can。 So， anyway。

let's go ahead。 For those of you that want to ask questions throughout the lecture。

please put them in， the chat and I'll keep my eye on chat。

That way we make things work out properly。 But anyway， so welcome to CS162。

Let's talk a little bit about what we're going to do today。

We're going to talk about what an operating system is and what it's not。

And we're going to hopefully convince you why operating systems are so exciting to study。

And of course， we'll say something about how the class operates as well。

And interaction here is important。 It is something that we try to encourage。

It's a little harder on Zoom and maybe it's a little harder on the first day where we're。

kind of popping through what materials we're covering。 But especially when we get back in person。

I'm going to be encouraging and Anthony will， be encouraging as well。 You'd all ask questions。 Okay。

So let's start by this particular image here， which is already 20 years old。

A newer version would be even more crazy。 But does anybody have any idea what this is？ Yeah。

if you look carefully， you see that it says the internet， right？

And so what's interesting is one could very easily argue that the internet is one of the。

greatest artifacts ever put together of human civilization。

And the reason for that is it basically ties together computer components throughout the。

world into one huge system。 And as a result， the level of complexity there starts to lead to all sorts of interesting。

emergent behaviors， which we'll talk about a little bit as we go on， but also obviously。

security concerns as well。 So the internet is really astonishing when you think about it。

It's basically all of these cars and phones and cloud computing and so on all tied together。

in one huge system and all of the people of course come with it。

And if you were to actually plot the number of people and number of IP addresses over time。

it's been growing essentially in this exponential form forever since the beginning， right？

1995 or whatever， beginning of the web。 And it seems that it is going to only saturate when everybody has at least one internet address。

but probably many others。 And of course， you're all probably well aware of IPv4。

which is the 32-bit address space， has been essentially saturated for a long time and IPv6 may finally be coming around。

But that may be a topic for another day。 So the other thing is that we have this huge system across the whole globe。

lots of components， in it， but we also have an incredible diversity of different things， right？

We've got everything from mainframes to workstations to PCs and so on。

And this general trend has been very interesting。 It's been that we started out with kind of computers per person here。

like one computer， to a million people。 And we're now in the number of computers per person being。

you know， hundreds or thousands， for each person。 So that's sometimes called the internet of things where you have sensors in your cars。

and in your walls and so on。 And this has really been an incredible change over the last couple of decades to the point。

now where， you know， we're not even aware of all of the things that are out there that。

are on the internet and monitoring us， which kind of leads to all sorts of privacy concerns。

But this astonishing curve on the sort of a log-linear scale moving downward in size is。

something that often isn't pointed out to people when they're talking about how rapidly。

things are growing。 And there's a time scale range that's also astonishing as well， right？

Everything from CAF references in the half nanoseconds or picosecond range all the way。

up into times in milliseconds to send things across the globe and even seconds in some， instances。

And that wide range is something that， you know， the operating system ultimately， which。

is the top of this class， is going to have to deal with。 And so that's also very interesting。 Okay。

so we're in a very exciting time frame now and you guys obviously pick the right。

class to study this。 The operating system itself are really at the heart of all of this。

So they basically take all of these incredible advances。 I was showing you lots of little things。

many things， even also some very big things， all， tied together into one big system。

And it's really the operating system that makes us all manageable。 Because if it wasn't here。

you wouldn't actually be able to use these things。 Okay， and the operating system。

as we're going to learn over the term， pretty much provides。

consistent abstractions to applications and programmers， even though the hardware is varying。

widely。 It allows you to manage resources that are shared among multiple applications and also。

deal with security concerns。 And some of the key building blocks。

which we're going to talk a lot about over the term， are things like processes， threads。

concurrency， scheduling， coordination， all of these things， address spaces， protection， security。

things that you've heard probably as words but haven't。

really had an in-depth understanding of what they really meant and how they were implemented。

And what's kind of exciting about this class for me is， since we're going to be working。

with a real operating system， we'll get into this later in modifying a real operating system。

you get an up close and personal view of how all of these building blocks actually get。

implemented and then， of course， how they all tie together。 Okay。 So， for instance。

here's something you do every day。 You take your cell phone and you search for something。 Okay。

that's pretty common。 And however， what's happening under the covers。 Well， what's happening is。

for instance， the cell phone reaches out to DNS services that， are hierarchical。

so there may be many servers that are connected to get a response。

And what that does is it turns your human readable name of the service into an IP address。

which then can be used to route hop hop hop over the internet to somewhere which might。

be a data center and you're going to hit a load balancer at the entry point。 And under the covers。

totally unaware to you that load balancer is then going to pick。

the next hop in which to forward this information。

And then maybe there's some customized servers that are busy performing your search or finding。

out that information you're interested in。 And there's probably some ads that are being generated and other compositing that's happening。

on the final web page to create a result that includes your results， maybe some ads， which。

then get forwarded back along that same path， typically along the internet back to the cell， phone。

And so that very simple thing that you take advantage of every day actually has a lot of。

really interesting pieces。 And sometimes when I think too much in depth about what's going on。

I'm astonished that， it all works。 And I think getting a sense of wonder as we get through this term that all of the things。

that have to work together to actually get your queries to work properly or other more。

interesting things as we talk out through the net， I hope you'll get a little bit of。

wonder out of this as well。 I love systems and I think that the fact that a big system like this can actually function。

is amazing。 And I'll be hoping that Anthony and I can give you a bit of a flavor as to how that actually。

even happens。 So what is an operating system？ Well。

it's not entirely clear to everybody exactly what it is。 And what do I mean by that？ I mean。

different people have different ideas。 If you were to look at all of the ideas or all of the responses from a poll about what。

an operating system might be， you'll probably hear some pieces of it。 It does memory management。

It manages I/O， handles scheduling of the CPU。 Maybe it communicates。

Maybe it handles multitasking or multi-programming。 So there's a lot of pieces。

but that's not so much what the operating system is。 It's what it does。

What about pieces like the file system or multimedia support for videos or video processing？

What about the user interface？ What about the internet browser？

Is that part of the operating system？ I have a little smiley face there because there was a time when Microsoft was claiming。

that the browser was a fundamental part of their operating system and there was all sorts。

of discussions about whether that was true or not。 And those kind of arguments come up all the time。

It's kind of interesting。 You might ask is this only interesting to academics？

Well it's certainly interesting to academics， but sometimes antitrust comes into play and。

if Microsoft was claiming the internet browser was part of their operating system and as a。

result everybody was using their browser exclusively， there might be some antitrust issues there。

So be that as it may， I'm hoping to give you at least the right signpost as we go through。

to figure out over time if somebody gives you a definition for an operating system， you。

at least will have a way to evaluate what they're saying here。

So really there's no universally accepted definition of what an operating system is。

Sometimes people say well everything a vendor ships when you order an operating system。

One thing that people maybe will agree on is that there is something called a kernel which。

is typically the one program running at all times on the computer that's like the core。

of the operating system and maybe everything else is either a systems program that ships。

with the operating system or it's an application。 This is not so bad of a definition but we'll get further on that as we go。

So a definition of operating systems could also include things like what's the layering。

So for instance they might say in operating systems that special layer of software that。

provides access to hardware resources through convenient abstractions so it takes complex。

hardware and makes it much easier to use。 Perhaps it protects access to the resources。

Perhaps it gives security and authentication of those resources so that only authorized。

people can use them。 Perhaps it gives communication so there are communication protocols like TCP/IP which you've。

doubtless heard about and we'll talk more about that as the term goes on but perhaps。

those kind of abstractions also are part of the operating system。

So you could look at it this way that really there's the hardware underneath and this OS。

is a layer between applications which are what you want to get done and the complex messy。

hardware underneath。

So what does the word operating mean？ Well back in the really old days this is how people made phone calls。

There was a switchboard operator that you talked to and she or he actually plugged into。

the plug board the right pieces。

There were computer operators once upon a time and perhaps that was what the word operator。

means but today probably people when they're talking about operating systems they are as。

we said talking about that piece of coordinating software that ties everything together and。

that's going to pretty much be where we're going here。 Now what's the system portion？

So operating here it's the thing that's operating the hardware。

The system portion is also an interesting question so what makes a system？

So many interrelated parts typically make a system。

Each potentially interacts with the others and when you get a big enough system sometimes。

the actual interactions that you end with are not what you expected。

And that's kind of one of the funny aspects of having a system is when it starts to get。

emergent behavior and some of the things we're going to talk about in this class is really。

about taming that emergent behavior and really robustness requires an engineering mindset。

which I'm hoping that Anthony and I can give you a good taste of having an engineering， mindset。

So you've got to handle errors meticulously。 You have to be careful about malicious or careless users and you have to be very careful。

when you start getting into locking which we will to design for correctness rather than。

designing something and testing it a bunch of times and hope that you got it correct。

So we're going to be designing for a correct system。

So system programming is going to be a very important part of this class and we're going。

to start you out actually at the very beginning getting a flavor for instance how do you talk。

to something like Linux or a Unix style operating system from the user's standpoint just to。

give you a flavor of what it looks like coming from above and then we're going to dive in。

pretty deeply and pretty quickly into what is underneath。

So for instance we can talk about the hardware software interface which is really one would。

say a question of virtualization。 So we have this program up on top that's running and we have this complicated hardware underneath。

that we want to give access to the software so that something controlled happens right。

and so you know you've all been through 61C I'm assuming so what's in the hardware while。

there's a processor there's some memory which can store lots of different flavors of things。

maybe some of the memory is devoted to the operating system each of these different colors。

here potentially represents a different process and that processor has a set of registers and。

those registers can be used to access memory so that it might be addresses stored in there。

Those registers can also be stored out into memory so that we can suspend one process。

and run another thing and that's going to be part of the multiplexing multitasking that。

we're going to be talking about。 And of course there's a cache in the middle here that makes things fast and we'll talk。

a little bit about that。 Page tables that let us do translation to get virtual memory and then you know once you。

get sort of below the processor memory level all sorts of interesting hardware come into。

place you know storage devices networks displays all sorts of things there are buses okay with。

controllers that let you control all this stuff and so if you really just looked inside the。

computer you're going to see a lot of stuff and then when you extend it out into the internet。

there's even more stuff and the interesting question is how do you even program this the。

level of complexity is so high and so you know that's the instructions that architecture。

really helps there okay that's going to be basically taking what's inside the processor。

and giving enough standardization that a program can hope to run on top of it but it's also。

going to be the operating system which is going to give us nice clean boundaries and。

virtualized views of that underlying hardware in order to make things work okay so what you。

learned in 61c was machine structures the C language the OS is going to take all the。

things you learned in 61c and abstracted away to help the application be easier to write okay so。

really kind of if we were to talk more about what is in an operating system we might start with。

the notion that there's an illusionist aspect to it which is providing clean easy to use abstractions。

of physical resources so if we look back at this previous slide all of these things okay many。

different devices different processors different capabilities some processors have GPU some don't。

all of that complexity needs to be virtualized in a nice clean way to make it possible to write。

programs and that's really the solution is thing so you're providing a clean easy to use abstraction。

of those resources and those abstractions are ones that you may use without thinking too much about。

them when you those of you that have written and compiled programs you might think of things like。

infinite memory because you're not worried about running out of memory right away you might think。

of files and users and messages these are all things that don't actually exist in the underlying。

hardware they're they're put together by the operating system as abstractions that are easy to use okay。

so so how do we virtualize the machine well i've taken this machine here and squashed it out。

and the operating system is going to be that key piece of software running on top of the hardware。

and making it easy for applications to work and so for instance what do we get out of the operating。

system well instead of an individual processor that is a CPU we get threads and instead of。

memory which is a bunch of bytes that aren't really tied together well we get address spaces。

which are have protection domains associated with them instead of random blocks in storage we get。

files and there's going to be some interesting lectures that we have about storage devices and。

how we get a nice file system out of them so instead of random messages being sent over ethernet that。

can be dropped at any time we can get nice clean abstractions of sockets which are cues that you。

put messages in on one side and they show up on the other side guaranteed right and so on top of this。

virtualized view of the hardware we can have a process which is an execution environment with。

restricted rights provided by the operating system and that process is a nice clean container okay。

it's got an address space that's a nice clean chunk of storage it's got multiple threads which。

will multiplex well on top of even a single CPU it's got those files it's got those sockets and。

when you write programs you're writing to a process abstraction not to these individual。

complicated hardware pieces so you take your compiled program you put it on top of a process。

okay it's it's got some system libraries linked in and once you compile it and link it and start。

running it it actually becomes the process okay and so um just to state that a little bit what。

as we go on you're going to get a better mental distinction between for instance the program。

and a process the program is a potential thing once it's instantiated and starts running it becomes。

a process okay so the application machine is the process abstraction provided by the OS。

each running programs in its own process and processes provide this nice interface。

it's nicer than raw hardware so that's the takeaway from these last couple of slides here。

and what's kind of neat about this class i think is not only are we going to talk about。

these abstractions but we're going to show you how they're implemented and you get to see。

how we go from you know the underlying bits and blocks and complexity of the hardware。

into some programming environment that's actually usable across a variety of different machines。

and you know the programmer's view is that things are going to run into process and so they write。

some programs they compile them they link in some libraries and now as a result you've got。

something that's going to run cleanly on top of the process abstraction for a variety of different。

hardware instances or even across different operating systems in some cases we'll talk about how that。

can work so and then of course the compiler is going to help us turn this kind of program this。

is see into a binary which is really kind of what the underlying machine really needs okay。

i'm hoping that many of you remember the C language and the notion of compiling and linking from 61 C。

you're going to need to get on board with that really rapidly we're going to start off at a fair。

clip here in this class we will have i'll mention this later we're going to have a review session。

on the C language it's still tba but coming up late this week or next week we're going to very。

quickly pop you in to start running basic programs and compiling things and building the operating。

system really early so that all of those easy things you're ready with so that when we start。

teaching you things you'll be able to move forward now there's good question in the chat about you。

know can i do well if i haven't taken 61 C you can it's a little challenging under some circumstances。

you know if you're going to try to go at this without having taken 61 C i would do my best to。

to find a set of slides and review quickly okay because you're going to you're going to have to。

know some of the things about the way CPUs work and and the C language and so on right at the。

beginning it's not impossible it can be done and we also know in this class from years of teaching it。

that 61 C is not really enough of an introduction to the C language to really have a working knowledge。

and so that's why we give you lots of resources in the first couple of weeks and hope to get you up。

to speed quickly on the C language okay so i hope i answered that question。

so what's in a process so remember the process is kind of our virtualized environment so the process。

consists of address spaces one or more threads of control executing in the address space。

and all sorts of additional system state like open files and sockets and so on and Anthony also。

mentioned you can find great ebooks on the course resources page that's true so one of the things。

thank you for bringing that up Anthony you you should all look at the resources page。

Berkeley library digital library has a license to all of the O'Reilly books those are the cool ones。

with the animals on them and we posted a couple of good starter books on the C language and get。

off of the resources page that as long as you're coming in from a Berkeley IP address or you have a。

virtual VPN excuse me tied in to Berkeley to get to the library you should be able to access those。

so for example so process is as we say an address space one or more threads of control and。

addition just additional system state and for example if you're on a Mac you might see this if。

you look at the set of all processes and or you can do the task manager if you're on windows or on。

Linux you can do ps uh a ux for instance we'll give you all the processes and what's interesting to note。

here is uh even when idle there are a lot of things running on your machine and this is kind of fun。

you should take a look and see how many things are running on your machine okay many and most of。

those processes aren't running all the time they're mostly sleeping but then they wake up on some。

event and they run for a while and they go back to sleep and uh you'll get a much better idea of how。

that all works as we uh go forward in this class so the operating systems view of the world is really。

that the operating system is uh got the hardware underneath that it controls and it's providing。

a series of processes each of which has um its own address space threads files sockets etc that are。

distinct from uh from other processes and so this is a virtualized environment um and uh we're。

going to tell you how that works as we go on okay are there any questions so far。

okay so so the OS um so yeah good question our threads unique to processes so um each process。

has a set of threads running within them okay and the address space uh is referring to uh a。

the set of all addresses that uh can be accessed from within a process we'll make this a little。

more formal as we go on um and it's protected from the address space of uh other processes and uh so。

by default unless you go to the trouble of of uh opening up channels the the addresses and the。

underlying memory that process one can access is actually different from the underlying memory。

process two can access and so the address spaces are going to be one of our uh key ideas for protecting。

processes from one another okay and um so uh so there are each process has a set of threads。

and address space uh that's unique from the other ones um there's another question can a single core。

machine run multiple processes absolutely okay so we will tell you we'll teach you how that happens。

so even if you had a single core processor you could have many processes that are all appearing。

to run simultaneously that's concurrency and we'll show you how that works adding multiple cores。

just allows more of them to be running truly at the same time rather than apparently at the same time。

okay um and so the what we're seeing here there's a question about are the process files different。

from the files that live on the disk the answer is uh what you're getting in a process is the set。

of open files that um the process has managed to talk to open those files are ultimately stored on。

disk and so you know any file that a process has is backed by the disk we'll talk more about that。

when we get into file systems so um so the OS translates from hardware interface to application。

interface provides running program uh within each of its own processes okay so another so we've。

sort of that's the illusionist idea we're virtualizing the underlying operating or the underlying hardware。

so that when um the program is running it's got a much cleaner uh container in which to run。

so um another thing that operating systems do in addition to providing that illusion of nice clean。

infinite memory etc is its acts as a referee and it manages the protection isolation sharing of。

resources um handles things like resource allocation and communication between processes okay and so。

this referee aspect is really uh one of the important aspects of what it is an operating system does。

as i've said uh for instance it protects processes from from uh overriding each other's memory or。

interfering with each other okay and if certain files are only accessible to some user then the。

operating system is going to protect those files from other users etc okay so um what i'm showing。

here just to make it a little more clear is i sort of now have a brown process and a green process。

and just the the highlight and the color is really kind of showing that these are different。

protection domains and for instance right now back to that question of could a single core machine。

run uh multiple processes and then my answer was yes let's take a look at that idea so we have a。

single core for instance processor and it's currently running the brown uh in the brown uh domain here。

or process and so there's a particular thread that's currently executing and um that current thread。

is uh got some registers and it's got some memory and that's uh this protection domain and um。

that process right now since the brown process is the one that's active if it actually tries to reach。

out the part of memory that's owned exclusively by process two it's not going to be allowed okay and。

that's part of the protection so if we wanted then to switch so we're busy running the brown。

uh brown thread in the brown process and we want to give the green a little time to run then what do。

we have to do well we have to basically package up all the state and was there from the brown and。

load the state from the green okay and so here i'm showing memory um remember the memory is the。

hardware piece down here and in addition there being brown exclusively owned blocks of memory。

there are some green ones that are owned exclusively by process two and so um if this brown。

thread tries to access those it's going to get what's called a segmentation fault or a page fault。

we'll show you what the difference is and um they'll fail okay and so um really part of what the。

operating system is doing is keeping track of who owns what and if we're about to switch to let。

the green one run for a little while what do we have to do well we have to take the current versions。

of the registers and store them into memory in the o。s。

memory probably in a in a thread uh basically， in a thread structure and then we have to load the green state in and we have to change the address。

space to be accessible to the green and then as we do all that in the operating system and then we。

let things run again and now after that's happened now the green process is uh running okay and so。

back to that question about could one single core on a on a processor do this yes that switching from。

that core running the brown process to the core running the green process is part of what the。

operating system does okay we're gonna talk much more about that and so now let's talk about protection。

just to make this other thing clear so here's an example of the green process is running because。

it's loaded into the processor um and it's now trying to access a bunch of things including the brown。

memory some of the o。s。 memory um maybe some storage notice that all of those things are probably or。

might be disallowed so the green thing shouldn't access brown memory the green thing shouldn't be。

able to go to o。s。 memory and modify it except for some exceptions we'll talk about later it shouldn't。

be able to go to disk uh unless it's really supposed to be owning that data and so in those。

instances what happens is the operating system kicks in and it will kill the process so that it。

doesn't get to do those uh misallowed accesses okay disallowed accesses and you'll get something。

called the segmentation fault and that process will also will actually be uh stopped and um。

typically some debugging state might be dumped out okay were there any questions on this。

I see that Anthony's running a some answers to questions on the chat too that's great。

okay so um I guess the question is about virtual box we'll let Anthony keep going on those so um。

so back to to our protection idea here so now i'm showing a bunch of processes um and uh one。

processor or one core let's say and now there's going to be a protection boundary uh and all of。

those things underneath the covers the disks the displays the networks the buses all of that stuff。

is going to have a protection boundary um put in put together by the operating system to make sure。

that these processes only access the things that they're supposed to okay so the o。s。 isolates。

processes from each other it isolates itself from other processes okay so um that means that a。

process can't trash operating system memory and even though everything is running on one。

processor in this instance that i've shown you we can do all of this protection okay。

so um now moving right along。

that's the idea of a referee um finally an operating system uh yes is that's a good question there。

is the o。s。 a process in and of itself so um yes and no and that's one of those things where。

different people might disagree what it's meant by there being a process i will tell you that the o。

s， has multiple threads that are running and they're at higher privilege than all of the process threads。

and so there there's a lot of different things going on in parallel in the o。s。

and they have control， of a lot more things um typically we don't call that a process that's part of the operating system。

but there certainly are o。s。 threads that are running um and you could ask me that question again。

in a week or two and maybe we could have more of an argument about that but just to close this out。

rather than saying that the o。s。 is a process um in this instance in way i'm talking about the o。s。

has a bunch of threads that are all working at really high privilege inside um and helping to。

produce this virtual view to all of the processes above so finally this idea of o。s。 is glue so the。

operating system uh being an illusionist and a referee uh these things are often nobody would。

disagree with those being part of the operating system what's interesting is once we start talking。

about glue um that's when some of the disagreements come up glue is really things that help uh make it。

easy for programmers to use the underlying hardware okay and those glue glue is really about common。

services such as taking storage and turning it into files providing a windowing system providing。

networking uh where you can actually transmit bits from you know Berkeley to Beijing and back and。

they actually make it there these are services that programmers find useful um and uh different。

operating systems and even different versions of the same operating system might differ in what。

services they'll provide okay but um in general o。s。 is provide libraries and running services that。

help to make things easier for programmers uh to use the system okay and um the question here about。

do cores have dedicated hardware to run o。s。 threads so typically not okay typically what happens is。

the same cores that we're running the user level processes will start running the o。s。 ones when a。

timer goes off and things start running or when the o。s。

when the process uh that's running user code， or application code makes a system call into the kernel then things will start running uh the o。

s。 threads will start running on the cores etc。 so um we will uh get into a lot more of these details。

okay so you'll you'll have a much better idea how this happens once we start diving into it um so。

good question though one that i do want to answer right now which is how does the o。s。

trust a process， to return control to it and the answer is it doesn't okay and in fact what happens is the o。

s。 has control， over timers that will go off and automatically transfer control back to the operating system。

regardless of what the user is doing and so the user program could be uh busy computing the last。

digit of pi which is one of my favorite things to do and um the operating system will still get uh。

to go again when the when the timer goes off okay and um we'll get into what syscalls and so on our。

later um but just as a quick answer here syscalls are not what timers are syscalls are when the uh。

user program actually accesses services so when it makes a file system read or write call that's a。

system call and we'll show you how that works so i。o as we've been alluding to is an important part。

of what an operating system handles and so really it's again turning the complexity of the hardware。

underneath into a nice clean abstraction layer okay and so for instance um when we start a program。

running uh we might pull parts of that program off of storage and bring it into memory so。

that it can start executing um or when we're um you know communicating remotely to Beijing say from。

Berkeley uh again the OS is going to help uh coordinate that i。

o so that um the what we think we're doing， is sending a byte stream actually gets transmitted as a set of packets over wireless or wired networks。

many hops in the middle of the internet to the destination uh over in Beijing for instance that's。

all handled uh by the OS as well okay and so that's another one of those common services that is。

typical okay and uh there are many i。o services so um you know finally we've got the the look and feel。

uh of a typical machine you're all aware of you know you've got your cell phone you've got your。

laptop it provides a set of windows the ways to do cut and paste and so on that's typically the。

look and feel and in um many instances there are at least libraries that provide this windowing。

sometimes that windowing is in the operating system and um we will talk more about this as we go。

forward as well um just as an interesting little bit on that um windows NT back in the early 2000s。

was a micro kernel operating system that actually had windowing and everything outside the kernel。

and that ended up being too expensive and uh from a time standpoint and so as a result Microsoft。

moved its windowing back inside the kernel of the operating system and that actually uh for time。

made it less stable and so sort of questions about whether something's in or outside the OS。

is an interesting question which we'll touch on as the term goes on as well。

there was a good question uh there about an alternative to time-based multiplexing。

um you should all look at the chat there Anthony's talking about the fact that OS is actually。

multiplex in time and space and the way to think about that is really that memory some notice this。

memory has some uh memory devoted to different processes and if we have more than one core。

then we can actually have different cores running on things that are in different parts of the。

memory or different parts of the storage simultaneously and the OS is going to manage that as well。

okay um and by the way for those of you that are worried that this is getting too complex too quickly。

I will tell you that we're going to um sort of throw out multiple cores at the beginning and just。

think about one process running or excuse me one core with multiple processes running on top of it。

to get that really settled in your mind and then we'll bring in uh multi-core after that because。

it's really an easy addition once you understand how to make one core work um and then also uh the。

OS often handles battery management power managing so on okay so lots of management management。

so if we were to put all these together you know what's an operating system it's a referee。

an illusionist and glue okay so those three things um will come up many times this term um as we talk。

about different aspects of operating systems and in many cases you're actually uh let's see here yeah。

you're actually going to implement parts of all three of these things uh in the operating system in。

your groups as the term goes on and so you're going to get a really nice internal view of how。

these things are provided by operating systems all right so why take 61c other than the fact that。

it's cool and the faculty who teach it are cool there might be other reasons right so one of them is。

some of you might actually design and build operating systems uh in your career okay and。

and it's possible more than ever now because we're getting these embedded uh internet of things。

style devices where in some cases people design their own little pieces of operating systems from。

the ground up uh just because these devices are limited um or you may end up uh working deep。

inside of Linux uh at a startup who knows so it's good to really have a good idea what's going on。

certainly many if not all of you are going to be creating big systems that utilize some of。

the core concepts here okay and so when you're designing the next big thing uh cloud system whatever。

um you're going to uh basically want to know what's happening under the cover so you can do a better。

job of it okay doesn't matter whether you build hardware or software kind of the concepts you get。

in 162 are really going to help out um there was a good question why not use rust uh rust has a very。

steep learning curve and is an awesome language but we're going to stick to see for now because it's。

more common so far in the operating system domain but i have to be happy to talk to you about rust。

in office hours if you want to come by and chat so all of you are certainly going to build。

applications that utilize operating systems okay and the better you understand them the better you。

will be able to use them okay so let me say now we'll say a little bit about who we are so whom i i'm。

john kubital it's most people call me uh kuby maybe because they can't pronounce my last name um。

it's uh i have a background in hardware design i was uh working on the alwatt project at mit um as a。

graduate student here's my chip this was the communication and memory management unit that i。

designed and this was one of the first parallel systems that had both shared memory and message。

passing in one uh in one system i have a strong background in operating systems as well so i worked。

uh at project athena uh as an o。s developer at mit i did device drivers and network file systems。

i worked on clustered high availability systems as well back in the day um。

tessellation here is an operating system that um i helped develop uh for um the par lab here at。

berkeley um i did a lot of work on peer-to-peer systems um and uh one of the first things i did。

here at berkeley was the ocean store project uh where among other things we talked about storing。

our data for thousands of years um and uh develop some uh different interesting peer-to-peer systems。

like tapestry and bamboo and it was one of the first cloud storage projects uh back before the。

cloud and athenaic has just uh popped on here he also was part of ocean store which was uh fun at。

the time um and um i'm also do quantum computing which is going to be less relevant to this particular。

uh class but um we're exploring architectures for quantum computers and CAD tools for designing them。

um most recently i've been part of the swarm lab or berkeley lab for the intelligent edge uh and i。

have a project called global data plane um and uh storage uh containers called data capsules we'll。

talk a lot more about that uh anthony also works with me on that project um and we have some things。

that we look at uh robotics on the edge with a project we call fog robotics okay and um part of。

this data capsules uh the intuition here is really these storage containers that you see。

uh down at the port of oakland in which i've been sitting in ships uh for uh the last uh six months。

basically that's our inspiration behind these uh data capsules which are cryptographically。

hardened containers of data and um we'll definitely talk about that later in the term so uh go ahead。

anthony here's uh who is he there he is well who am i i'm anthony joseph i'm a chance。

was professor in ekes i sit in the rise lab i'm part of uh the rise lab and i recently took on the role。

of faculty director for the college of engineering's fung institute for engineering leadership。

so i work on a number of different research areas as kuby mentioned i'm part of fog robotics。

and gdp i also work on machine learning and in particular secure machine learning so that's。

where you have machine learning in the presence of adversaries so you're trying to make decisions。

like for example of something uh malware or not and an adversary knows that you're using machine。

learning and they're trying to manipulate that answer so that for example their malware is classified。

as non-malicious i also cooperate the detour security cybersecurity test bed that's the world's。

largest public cybersecurity test bed and it's used by industry by government researchers and。

it's used to teach a lot of students at a lot of different universities and colleges。

previously i've worked on a bunch of different projects in the system space so for example。

moden which is a drop-in replacement for the pandas python library it delivers up to 100x。

performance and allows you to take advantage of the fact that modern CPUs are multi-core and we have。

tens to hundreds of gigabytes of memory available on machines i also work on cloud computing uh so。

patchy mesos was one of the projects we developed here at berkeley and it's a a project that lets you。

basically manage applications running on very large clusters of machines also i work in。

computational biology so we developed pipelines for being able to process whole human genome。

sequences at 250 gigabytes a pop that's a lot of data when you look at population scale numbers of。

say 10，000 genomes you're talking about anywhere from terabytes to petabytes of data that you want。

to work with so we made it very efficient to be able to work with those large data sets also as。

could be mentioned we had a project together tapestry and peer-to-peer networking i've also worked on。

mobile computing and wireless and cellular networking some of the outside activities i've done so this。

hybrid format is something i'm very familiar with so back in 2015 and 2016 we created a set of five。

different courses on working with big data and Apache spark we enrolled over 240，000 students and。

had completion rates of 11 to 15 percent which is pretty surprising because typical completion rates。

are around 3 percent i'm also co-founder of a startup in the life sciences space called。

in iGenomics and it's basically taking the work that we did in amp lab and rise around computational。

biology and commercializing that technology and so we work on treatments for rare diseases so with。

that i'll turn it back over to kuby and before we lose Anthony just so you know we're gonna we're。

gonna we haven't come up with the exact alternating plan here yet but you'll get to have some lectures。

from Anthony as well so he'll be a great addition here a lot from me yes indeed。

all right so we also have some tas that you're going to get to know very well。

and rather than having them come today since everything's virtual i figure in our first in-person。

class they will come to there and we'll introduce them but you'll be interacting with them in these。

first couple of weeks even already so about enrollment you know i figured i should say something about。

this we've gotten lots of email unfortunately this class is very limited this term more so than it has。

been in the past for various reasons right now the class is still paying at 327 students。

however we're working on securing another section which might let a few more students in。

so be watching that but please don't email us for special reordering on the waitlist or whatever。

because Anthony and i don't really have any control over what order people get in。

but it's it's extremely limited and like i said there may be another section we're putting together。

it's very important to note that this is an early drop deadline class which means that。

the drop day is the Friday of the second week okay so that's coming up on the 28th。

if you know we have a lot of people trying to get in this class if you're not serious about taking。

the class please drop early because the department's going to continue to admit students as other。

students drop and so you'll let people that are trying to get in the class get in and we will close。

off the waitlist sometime in the next couple weeks and you know we want to make sure that everybody who。

can get in can get in and in theory if you stick around for the first two weeks it's going to be。

heart much harder to drop and the reason we do that is because you're going to be part of project。

teams we're going to ask you at the beginning of the third week to put together your team and。

we want to make sure that teams stay functional without losing members so think carefully about this。

and really only come to stick around the next two weeks and join up with project groups if you're。

really intending to be here for the long haul okay and you know with that being said we're going to。

keep trying to bring people in so if you're on the waitlist or your concurrent enrollment or whatever。

you got to be doing the work because if you don't you know you might have us let you in the class。

and you'll be we'll be lost at that point every year that I teach this every term I teach this。

there is somebody who forgot that they were on the waitlist and weren't doing any work and kind。

of figured they weren't in the class and they discover sometimes not until you know weeks or。

months into the term that they're still in the class and that gets tricky to drop at that point。

so just you know if you're on the waitlist do the work if you're not intending to keep the class。

make sure you get off the waitlist okay are there any questions on that。

and as far as the question about piazza so everybody who has the potential to get in the class。

should potentially have been added to the class unless you're concurrent enrollment and we may be。

fixing that soon as well so just because you're able to access piazza and our autograder by the。

way doesn't mean you're in the class only the enrollment that's officially there you have to go to。

to the the university sites there to figure out whether you're in the class or not that tells you。

whether you're actually in the class but if there's a potential for you to be in there please do the。

work okay are we good on that all right so infrastructure the website is cs162。ecs。berkeley。edu。

we also have cs162。org as well and the piazza is linked is linked off the home page we're going to。

be putting the lecture recordings tentatively up on the home page we hope to be able to maybe。

continue with this throughout the term but you know we're all hoping that this everything becomes。

back in person shortly okay i see somebody asking about the course calendar so if you're。

are on the home page and you can't view the course calendar that's likely because you are in incognito。

mode you're going to need to be logged in as as a student okay so our textbook is uh。

Anderson and Dallin operating systems principles and practice the home page has our schedule on and。

also has suggested readings this is one of the better textbooks that we found and so。

i would say people learn in different ways reading the suggested chapters out of this book。

might be your thing and i would actually recommend it because it's a pretty good book。

we also have some additional ones supplementary material that you could get at。

operating systems three easy pieces there's Linux development third edition by Robert Love。

we also have some other things that are linked off of the resources page some more Riley books。

to help you along as well okay and there's also the latter teaching of C which is available off。

the resources page as well okay and i even put up some research papers occasionally on resources。

and i'll reference them throughout the term to get a little bit of a flavor for where some of。

these ideas came from okay so our syllabus is the following we're going to talk a lot about。

OS concepts how to navigate as a system programmer so we're going to start off with things like what's。

process IO networks virtual machines and then we're going to learn about concurrency so we had a。

lot of questions from people today about can one CPU can one CPU have multiple processes etc and the。

answer which we said many times was yes and we're going to show you basically how you can get。

threads scheduling locks deadlock scalability fairness etc so from the one end of the spectrum。

is how to get one end of the spectrum is how to get concurrency out of a single processor the。

other end is how to program with locking and so on and so there's going to be a number of weeks where。

we where we work you through some of these ideas part of that's going to be what's the address space。

is really and we're going to talk about virtual memory and address translation。

protection sharing these are all 61 C concepts which we're going to remind you of we're going to。

talk about file systems and fascinatingly you know how do you go from individual blocks on a disc to。

something you can think of as a file that contains a video or something and is in a you know a。

directory that has a long path name we're going to talk all through all those details and different。

file systems as well so we'll start with IO devices and then we'll work our way all the way up to files。

transactions databases etc okay and we're going to then toward the end of the class we'll start talking。

about big distributed systems so I started today talking about the wonders of the internet and。

tying you know sort of every device in the world into the internet and once you've got that that's a。

huge distributed system and while this class starts in the small we look at sort of small。

systems on single nodes we're going to expand our way way up to all sorts of distributed systems。

protocols RPC NFS distributed hash tables we'll talk about consistency scalability multicast。

and you know cloud computing and sprinkled in through all of this but especially as we get。

toward the end it's going to be things about reliability and security we'll talk about fault。

tolerance protection talk about logging and how that can help and so on for reliability okay and clouds。

all right this is a learn by doing class so be prepared to not only do your academic studies。

but you're going to be programming and working in team so we have both individual homeworks。

which are done by yourself which help teach you kind of tools of the trade and individual ideas。

sockets thread programming and so on and group projects okay and notice that there's a homework。

zero and a project zero these are very important because they you do these in the first couple of。

weeks so you should look at the schedule we're going to start you off by with homework zero right away。

and project zero which doesn't need a group yet it's going to be you done in your own and these。

in homework zero project zero are all about you learning our infrastructure so that you can hit。

the ground running and really get moving with this class okay and so the group projects are。

going to be the other ones one two and three are actually going to be in groups of four and you're。

going to start off on the beginning of the third week by telling us what groups you know who's in。

your group and what your preferences are for sections and so on and then you're going to be。

working with your group the rest of the term to develop some things inside the operating system。

okay and so these group projects have four members you know I like to think it's。

thou shalt only do four you should not do three and you should not do five right you're going to do。

four members and you're basically learning about how things work in the real world and we need to。

make sure that you're all in the same section or at least have the same TA so we have some。

some cases in which we have to spread people out a little bit but really this is going to be about。

you making sure you should have one TA that was able to know how you guys are doing okay。

and communication and cooperation is going to be essential so you know I'm going to reiterate。

this and Anthony will reiterate this throughout the term but you need to set up regular meetings。

with your group and what's hopefully awesome about this term we will have to keep our fingers crossed。

as we'll be in person for the first time in almost two years and really sitting down at a cafe。

okay we've got that cool little cafe and ancivari these days or you know whatever and talking with。

your group members is going to be essential to having a smooth to have a smooth group interaction。

okay and together you'll work on your design documents and really I really talk a lot about。

face-to-face because however good our social media apps are Slack， Messenger， Facebook。

whatever your， favorite thing is it really doesn't replace face-to-face and I've had many dysfunctional groups over the。

years and they were all people that somehow all groups that didn't meet regularly and you know。

only used email and then got upset when things weren't understood by other partners and whatever so。

plan on really meeting your team regularly okay there's a question about discussion sessions。

are they only on Thursday and Friday well right now there's actually sections on Wednesday。

Thursday and Friday we are trying to fix that because we'd like everything to be on Friday。

if we could because then it makes what you learn in section a little easier with respect to the。

lectures but certainly drop us a note on piazza if you have a strong preference for something other。

than Friday but right now we do have a few sections on Wednesday and Thursday everyone in these groups。

should have clear responsibilities you'll evaluate your teammates at the end of each project to kind。

of say what your view was about how they do we'll talk more about that at the end of project one。

and you're going to learn basically about how to work as a team and typically people who try to。

divide things up by task oh yeah you do you know bullets one two and three and i'll do bullets four。

five and six really doesn't work well and you'll see why that is as we get a little further in。

because you know you go off your separate ways and you come back and they don't integrate properly。

and you know then you got a panic and figure out what to do so there is a question about will。

things still be recorded if we're in person so we are set up for screencast so yes i think。

the other thing is we might do this zoom kind of thing even in person we're not quite sure yet that's。

going to depend on how resources go you should try even when things are recorded though to come to。

to lecture because then you can actually ask questions and see how things are going。

you know group projects are also about communicating with a supervisor like you wouldn't。

the real world and that's going to be your TA and so we'll talk more about how to make this work but。

the group projects are essential to this class and they are a little slice of reality okay。

so getting started everyone doesn't matter whether you're on the waitlist or in concurrent。

enrollment if you have the chance of getting into this class start homework zero right away。

okay if it's not up yet it's going to be up today i think um project zero will be early next week。

get going on that as well okay oh and uh hear from the TAs that homework zero is already out good。

it'll help you do things like get your github account set up the virtual machine environment。

get familiar with all the tools how to submit to the autograder etc okay um first two weeks you can。

attend any section you want i think we'll give more details on piazza about this but once we form。

groups then the section attendance is going to be mandatory um and because we want to make sure that。

again that your TA knows how you're doing and also it's important to go to section so you can get。

your questions answered because we don't want anybody lost this is the uh no student left behind。

kind of mode here okay um so projects are going to be choir uh programming in C and so you're going。

to need to be comfortable with pointers you're going to be need to be comfortable with memory。

management and debugging with gdb um and so this is going to be a larger and more sophisticated。

code base than you ever ran into in 61c um so one of the things that we haven't posted exactly when。

yet but it's coming up in the next two weeks is a review session on the C language to kind of。

give you a bunch of things to think about but we also have uh resources on the course website。

we have ebooks on git and C there's a programming reference still in beta that was written by folks。

at Berkeley uh which is basically in the uh ladder uh slash ladder and uh first two uh sections are。

also going to have some dedication to programming and debugging review okay so the tentative breakdown。

for grading is 36% uh over three midterms 12% each um the tentative days are thurs our thurs days。

two seventeen three seventeen four twenty eight um time is uh not quite yet set it's going to depend。

on when we can get rooms and uh the midterms are um mostly going to be focused on the piece that was。

in that midterm chunk so thinking this is dividing the term into three pieces but we're going to。

assume that you remember everything from the previous midterm because uh there may be questions。

that have a context based on previous things so the midterms are certainly going to be focused on。

the new material but you uh maybe ask things having to do with previous material um all right and uh。

36% on projects 18% on homework etc okay um participation is going to matter so that's another。

reason for going to section okay etc so the other thing we always have to talk about is there is。

the personal integrity uh student honor code which is you know as a member of the UC Berkeley community。

I act with honesty integrity and respect for others okay so explaining it you got to be careful all。

right do not just give people your answers don't copy answers from other people because we're running。

software tools to catch that sort of thing and it's also very dishonest okay so explaining a concept。

somebody in another group uh might be okay conceptually discussing maybe algorithms or testing strategies。

might be okay discussing debugging approaches with other groups okay searching online for generic。

algorithms uh these things are probably okay okay what's not okay is sharing code or test cases with。

other groups uh copying or reading other groups okay copying or reading online code or test cases。

from prior years okay helping somebody in another group to debug their code okay we had we've had。

situations in the past where somebody from one group sat down with another group and helped them。

debug okay and the net effect was both groups got kind of tied into a into a cheating scandal okay。

so you do not want to do that um and it's it's not honest either okay。

so if you're not sure certainly ask your TA whether something's okay but we're going to be。

running comparisons of project submissions and homework submissions against prior years and so。

just do your own work thanks everything easier for everybody okay。

you know and don't put a friend in a bad position by asking for help that they shouldn't give okay。

we've we've had you know students get tied up because they were gilted into giving somebody their。

answers we're just just don't do that to your friend okay so goals from lecture interactive okay。

ask questions in the chat for now but as we go forward um you'll get to actually hopefully ask。

them in person all right um you know let's finish up here we have a few more minutes but。

just uh unless they're actually i'm going to pause for a moment and see are there any more。

questions about adminest trivia there is somebody who asked should they start looking for a group。

even though they're on the waitlist you know i would watch where you are on the waitlist and maybe。

start thinking about who you might want to work with um you know we don't form our groups until after。

we close out the waitlist but um you know it wouldn't hurt to know somebody uh that you're thinking you。

might want to work with so if you're on the waitlist you're not in the class it's possible still that。

you could get in it's also possible you might not so um and the question is is the participation grade。

just from section attendance um it's section attendance it's uh office hours it's um potentially。

class attendance uh maybe we might do that um we'll let you know but just participate and we'll be。

watching okay so to close out today uh you know what makes an operating system is exciting and。

challenging um one of the things i like this picture okay because this is really talking about the world。

as a single huge system okay from little mem sensors this is a um a micro uh i don't know insect。

that can walk that was actually fabricated out of silicon um cars you know you start talking about。

Teslas these days that are constantly tied in all the time and getting updates continuously。

you've got big cloud systems you've got huge clusters really the world is one big system and。

that's exciting because uh there are first of all how do you make this work but secondly there are。

all these interesting emergent effects when lots of things are talking to other things and the。

complexity of the system starts giving an interesting behavior that you weren't expecting now sometimes。

that behavior is good sometimes that behavior is not good um and so you know most of what we do in。

this class we'll be talking about how to um to uh rein in the complexity to try to get a predictive。

response out of things but um it's still quite interesting okay um you know the other thing is。

really technology trends with Moore's law um here's a you've heard Moore's law probably from the day。

you got here to Berkeley and if you kind of look really what was interesting was if you look at。

this graph over in the left um Gordon Moore was asked at a conference back when the 4004 was the。

most sophisticated thing uh out there you know what's going to happen in the future and he drew a couple。

of points on a log linear scale and he drew a line he said this is going to happen now that's。

on the one hand patently ridiculous because it's a couple of points on a log linear scale means。

that drawing a straight line was predicting exponential growth uh but it was true okay and for many many。

many years Moore's law was it okay which is pretty exciting uh that we've had this uh doubling in the。

number of transistors that went on for years okay it's been slowing down of late but that means。

the complexity of the individual components growing at a rapid pace uh leading to the complexity of。

the world system growing at a at a rapid pace leading to a need for good operating systems design and。

you guys to be able to help with that okay um one of the big challenges that happened along。

the years is you've probably seen this somewhere around 2002 we were taking Moore's law and turning。

it into constantly growing CPU performance and so you could be lazy and say well this the computers。

of this era are not fast enough for what I need uh but it's okay because I'll just wait a couple of。

years and um since performance was doubling every 18 months that was fine the interesting thing。

however is that uh around 2002 that stopped working for lots of reasons and we got multi-core now all。

of a sudden we had to figure out how to build big parallel systems okay and that uh that led to。

all sorts of interesting needs for new ways to program okay so， another problem was power density。

um if you look yeah so we don't have to worry about um Anthony just put you don't have to worry。

about participation while we're virtual so another challenge here was power density and really if you。

didn't um slow down the way that uh things were getting faster you're gonna have to have uh the。

power of a rocket nozzle in laptops on your lap which is probably a bad idea so part of what。

happened with multi-core was really about uh coming up with another way of using all those transistors。

okay and then in about 2007 people started talking about big chips with or many cores okay like this。

is the Intel 80 core chip that was in 2007 um 2010 had 24 tiles of two cores each and now uh 56。

cores times two is certainly there in the high server end and so you know the question about how。

do you program these things standard joke for a long time was well i've got all these cores i'll use。

two of them for video and audio one for word processing one for my browser and you know uh。

the rest of them for virus checking that's it yeah um you know so that really started bringing on。

the need for parallelism in this class we fully embrace parallelism um and um that's part of you。

know the interesting parts here right okay so um Moore's law has been ending um we're no longer。

getting two times transistors every 18 months or even every 24 months um and so that's actually。

changing things a little bit again uh in different ways and we'll have to see we'll talk more about。

that as we go storage capacity still growing drastically okay and this is sort of showing capacity。

on a log linear scale and so we're you know um one of my favorite SSD uh items that fits into a。

three and a half inch form factor is uh has a terror excuse me has um terabytes uh multi terabytes。

ssp okay hundred terabytes on one little uh three and a half inch drive okay and we'll talk about that。

but a hundred terabytes is not a small amount of memory and a three and a half inch drive is not。

very big so it's kind of we have a future of a ridiculous amount of storage and uh we'll talk。

a lot about how to protect that storage so it doesn't get lost um society is increasingly。

protected connected which means we have all of these security breaches going on we're gonna talk。

a lot about security as we go on okay um capacity the network keeps increasing okay um you know that's。

another interesting thing it means that we can communicate with the far reaches of the world。

ever faster which means that our system that we're tying together is doing ever more things ever。

quicker and uh that could either be really fast way of uh failing or uh very fast way of getting。

additional functionality depending on how you design things now the question here is do you need。

161 to take this class you do not um but uh 161 is a great class so i highly recommended either before。

or after this one okay um and uh we can talk more about that if you like so not only pcs are connected。

the internet of course um lots of uh phones but even phones aren't the big thing these days little。

devices um you know we all have a fit bit uh you know or an apple watch we all have little sensors。

everywhere okay so that's really this slide again okay we're down to the internet of things where。

every person has hundreds of CPUs working for them every day okay so what's an operating system。

again well it's a referee managing resources protection isolation it's an illusionist providing。

clean easy to use abstractions it's glue with common services and throughout the term we're going to be。

thinking a lot about that okay and we're going to teach you a lot about that so i'm going to end。

there and um the thing to keep in mind uh is as we go forward when i say in conclusion okay typically。

people tune out but really what i'd like you to do at that point is bring your attention back。

so that i can give you a quick summary of what we talked about so in conclusion we want to talk。

about providing convenient abstractions to handle diverse hardware we're going to coordinate resources。

and protect users from each other using a few critical hardware mechanisms simplify application。

development providing standard services we're going to provide fault container fault containment。

fault tolerance fault recovery and cs 162 is going to combine things from many different fields together。

and i'm looking forward to going through this with you and uh let's have a great term。

thank you thanks for posting thank you。

[silence]。

P10：Lecture 10： Scheduling 1 Concepts and Classic Policies - RubatoTheEmber - BV1L541117gr

Okay， welcome everybody to the first post midterm one lecture。

Yeah， you survived。 So we're actually going to do a little bit of a change in topic。

Let me make sure。 Let's see。 Can everybody see my slides？ Also in cyber space。 Okay。

so if you remember。 I wanted to review a couple of things that we were doing just at the very end。

And so we can close out kind of a bit on synchronization here。 So， first of all， if you remember。

we talked about semaphores last time in more detail。 And there's two uses of semaphores。

So semaphores have an initial number。 Value that you set when you allocate them。

And if you set that value to one， you basically just get a mutex or what's called a binary semaphore and you can use it for locking。

And so you'd use it like this， where you do the P operation down and the V operation up when you're done。

And if two folks try to do that semaphore P at the same time， one of them gets put to sleep。

And this is a purely atomic operation。 So it's not possible for two threads to get through there by accident。

Okay， so it will atomically decrement the value。 And if you're would go before zero。

put you to sleep。 We also looked at the fact that we could do scheduling constraints by setting the initial value to zero。

And that might allow you to do a joint operation。 So you set it to zero。

you go to sleep by trying to do a P operation。 Anybody else could wake you up with a V。 Okay。

and then finally， and so this is the example of thread join where the original parrot thread。

let's say， goes to sleep and then the finishing child thread executes a V and wakes them up。 Okay。

and then finally we had the bounded buffer solution for the coke machine。

And this was a good example for three semaphores。 And if you remember the reason we had three semaphores was we have two conditions and a lock。

The two conditions have to do with bounding the maximum number of coke cans in the machine and saying that it doesn't make sense to have a negative number of coke cans in the machine so we're bounding the two sides。

Okay， and if you remember the code kind of look like this for the producer in the consumer。

This key pattern here is that we always protect things like in queue and because those are those are operations that could get screwed up if multiple threads go in them and so that's why we have new Texas around them。

And then we execute a semaphore P on the empty slots to make sure there is something before the producer goes in and the flip side for the consumer。

And so， you know， if you look， what's in red here are critical sections in the locking sense just to protect the cues。

And then we have this signaling that when the producer finally produces something they'll wake up somebody who might be sleeping。

And when the consumer kind of finally empties a can out they might wake up a producer。 Okay。

so before we leave this I just wanted to see if there were any last minute questions on this。

Semaphores are very common in operating system so。 All right， good。 So， however。

we said there's something even better。 Okay， a monitor which is a lock and zero or more condition variables。

And actually if you only have zero condition variables it's not that interesting。

And the condition variable was specifically a weight queue that you can go to sleep on with the lock being held that's the key idea here。

Okay， so unlike any other weight queue。 And the condition variable weight queue you grab the lock you check your conditions then you go to sleep if they're not satisfied。

And it's that weirdness， or difference in API that really makes them so powerful and easy to use。

There are three operations typically they got different names depending on what the packages are。

but roughly a weight， a signal and a broadcast。 And the rule is always hold the lock when doing any of these three operations。

Now， I know there are many of you who would say well why do I have to hold the lock to do a signal or a broadcast。

There are various reasons for that and depends a lot on the scheduling package as to whether that's legal but for now we'll just say。

always hold the lock around everything。 Okay， especially in this class。

Are there any questions on the interface。 So we gave you this typical structure so if you're thinking about a monitor program this is one way to think about it。

You grab the lock。 You check and see whether conditions are met or not。 And if they aren't met。

then you go to sleep。 And notice that that weight operation always happens。

Like a semaphore P which might not put you to sleep a weight always puts you to sleep。

This is the key interface aspect。 And then when you wake up with typical Mesa scheduling you always have to loop back and check your condition again。

And then you might somehow reserve the thing that you found you've got and then you can unlock and then when you end you kind of lock again and signal that you're done。

This is a pattern。 Okay， and we did that with the readers writers example。 Okay。

And this was the readers writers example can have one writer or multiple readers but never a writer and reader will meet。

Okay， and actually unlike on the exam question， whatever it was。

The three C maybe you can't have two writers either。 Okay， so one one writer at a time。

And that was the motivation for the code that we had here。

which was this was a reader code where you grab the lock。 See the pattern there。

You check and make sure there aren't any writers either active or sleeping ones。

And if there are you become a waiting writer and you go to sleep。

And then when you wake up you're no longer a waiting writer。

you loop and you keep doing this until you get through without there being any writers in the system and in that case。

you do a plus plus saying， you're an active reader， release the lock and do the database access。

and then on checkout， you acquire the lock again， you decrement you're no longer a waiting reader。

And then there's this condition that if there are no readers left。

that are active but there's a waiting writer then you go ahead and wake them up with a signal and then you eventually release。

Okay。 And so why do we release the lock at this point。 Anybody remember？ What was the story。

Why do we release at this point。 That's right。 Remember this entry things not is not preventing access to the database。

What it's doing is it's protecting the entry conditions to the database。

We need to release the lock so other threads can come in and classify themselves right。

And then the writer is similar， a little bit the same but different。 Okay。 And so here。

our entry condition for the writer is there can't be any active writers or active readers。

in which case， if there are either of those we go to sleep。 Otherwise we wake up， we do our access。

which is a modification style access。 And then when we acquire the lock again we're no longer an active writer if there are any other waiting writers we wake one of them up。

Otherwise， if there are any waiting readers， we wake them all up。 And then we exit。 Okay。

And so again， why do we do a broadcast down here instead of signal。

Might have multiple readers wake them all up， right。 Okay， any questions on this。 Yeah。 Yep。

right here you're saying， absolutely， get my little。 So right here， up， wake up。

And then we'll get more than one waiting writer。 Ah， well。

you just anticipated a couple slides I was going to do here so the question is。

could we just to get rid of the check and just wake up a writer anyway。

And then we'll get to that as well。 Yes， because in that instance。

what would happen is they would check in that loop。

Now notice that what we do get by doing this set of if and else is。

is we make sure that we give priority to writers over readers。

And then we'll get in broad signal the writer， and then broadcast to the readers。

It's not clear whether one of the readers would wake up before the writer and so we would actually have violated what here is a priority of our policy。

which is always， let the writers go first。 Correctness wise， it would be fine。 Okay。

it wouldn't violate the one writer or multiple readers。 Correctness condition。

but it would violate the policy， but it seems to be what this particular code has right the policy is that writers get priority over readers。

Okay， good。 So that's actually leads to， you know， why give priority to writers。

There's actually a couple of reasons for that right one of them is that if you look at typical traces there are more reads and writes so giving priority to the writers is not a bad thing。

The other is you can imagine writers are making the data more up to date and so you get the writers or the readers a chance to get more up to date data。

Okay。 That's not required。 You could do any other policy you want and in fact we even have done that another exams in the past。

The question here about why releasing the lock again I'm assuming the person who asked us in cyberspace talking about this release the lock up here。

The answer is we have to release the lock up there so that other threads can come in and classify themselves。

Okay， because if we hold the lock， then no other thread that comes in could get classified as a reader or writer。

Okay。 Now， the question that was asked is a couple here one is can the can the reader starve。

What do you think。 Can this lead to a starvation condition。

It's different from an incorrectness condition。 Who thinks it could why why why did it start go ahead。

That's right。 So if there's a continuous stream of writers the readers might never get to go。 Yes。

Okay， so if that's a use condition for you you might have to design your code slightly differently but monitors are powerful enough to do that。

What if we erase the condition check we just had that question right so what if we redraw out this。

Okay。 Will it still be correct。 Yes， it'll still be correct because of the while loop。 Okay。

at the entry way and that's kind of one of the reasons that Mesa is so much more preferred than the horse semantics is you can also be a little sloppy。

Okay， you can wake up as long as you wake up more than you need to you know you'll still be correct。

The danger in these kind of situations is you could wake up not enough of them and then the thing would just sort of deadlock。

Okay， so we don't want to do that。 Actually， I guess it's kind of a live walk will be more specific about that。

In a couple of lectures so， and then we could just turn this signal into a broadcast and wake all the writers up。

Why would that still be correct。 Yeah。 That's right only one writer would get it and the others wouldn't and the way to think about this is because of that lock at the beginning of the code。

All all threads entering the system are serialized by the lock so you only have them look one at a time at the conditions。

Okay， and so one at a time even if there's a thousand writers one at a time to go through the first one will get the ability to be an active writer the rest will be waiting later。

Okay， and then finally， what if we only use one condition variable。 Okay。

so don't separate between reads and writes and just say well it's okay to continue。 Okay。

now it turns out that what I said about the loop is correct so we won't get incorrect behavior but what could happen if we don't use broadcast instead of signal。

Yeah。 That's right， because if the readers and writers are all on the same queue and we only wake up one we might not get the type of waiter we want。

Okay， and so， so for instance what if we turn okay to write an okay to read into a single okay to continue so this is different code here now see the red。

And we have this scenario where our one arrives， then w one are to arrive。

well our one is still working。 And so then when that reader goes to check out。

If we only signal one。 Waiter than what will happen is we'll actually end up signaling the wrong person right we'll signal w one。

but w one to wake up and say oh look， there are readers in the system maybe this doesn't work so we have to make sure that we get it correctly。

There， okay。 And so we put a broadcasting here just to make sure there's enough folks that wake everything up。

All right， and this is actually particularly challenging on the the writer the。

well it's challenging on both sides so basically you want to just broadcast。 All right。 Now。

our monitors fundamentally different than semaphores。 Well， you might suspect the answer is no。

because we managed to somehow do a very complicated cue。 You know。

for the coke machine right so semaphores were pretty powerful。

So if they're really equivalent it seems like if we have semaphores we ought to be able to make monitors。

Doesn't it sort of like a， you know， completeness from a synchronization standpoint。

And the trick though is we got to be careful。 So first of all locks are easy right monitors have locks semaphores you start you initialize it to a one you got locks easy。

Okay， promise it gets harder from there right so what if we try to implement condition variables like this weight takes a semaphore and does a semaphore P and signal does a semaphore V。

Does this work。 How many people think we could implement monitor condition variables this way。

How many people think we can't and if you raise your hand you have to tell me why。 Go for it why。

Right， but let's suppose that we could put any value of a semaphore in here we wanted。 Yes。 Yeah。

so the problem with this is we grab the lock semaphore and you do a weight。

On a condition variable semaphore you're going to go to sleep with the lock。 Oh。

everything's broken。 Okay， so this is a bad implementation right off the bat。

because you can't sleep with this particular semaphore。 So that doesn't work。 Okay。

Does this work better so wait releases the lock， then does the semaphore P on the condition variable。

and then re acquires the lock before exiting wait。 And then the signal just does the semaphore V。

Okay， so this looks a little better because it doesn't lock up because of the because of holding the lock and going to sleep right because you see when you do wait you release the lock first。

Okay， but does this work。 Yes。 Great。 So this is still broken。

because remember that signal is not the same as some of the because if you signal first and then wait with this implementation。

they'll never wait。 Whereas condition variables you go to say wait you'll always wait。 Okay。

so this is broken。 Everybody see that。 Prom is semaphores or symmetrical condition variable signal is not。

Okay。 So what can we do。 Well， you know， and you can say here what if a thread signals and nobody's waiting to know up。

Right。 So what if a thread later weights， the thread weights。 Okay。

so if a thread signals in a forest and nobody's listening nobody listens， right。

Whereas if you do a V， and nobody's waiting。 You increment the semaphore and if the thread later does P you decrement and continue。

And so this will not have the property that every time you fall wait， you will sleep。 Okay。

So everybody see the problem。 This looks broken。 Maybe we can't do it。 Well。

the problem with the previous try courses that P and V are commutative result is the same no matter what order they occur in condition variables aren't。

So if you look， you could say， well， does this stick fix the problem， wait， releases the law。

does a semip and acquires and signal says if the semaphore queue is not empty， then you do a semiv。

Does this work。 It works， but it's illegal。 You're not allowed to read the value of a semaphore。

Okay。 So， there's a race condition here， signal or can slip in the wrong spot。

But it actually turns out it is possible。 And I'll give you a hint。

If we keep a condition variable integer of all our own that we use to increment before we release the lock。

then we can keep track of how many sleepers there are。

And the signal or can look at that because that's not illegal。 Since they have the lock。 Okay。

so here is an interesting example where having the lock around a single actually is it would be crucial to this particular implementation working。

Okay， because if you didn't have the lock and you tried to do check a condition variable or check that integer variable。

And you don't have the lock， then somebody could change it out from under use that problem。

All right。 Not going to belabor the point。 So bottom line is can make monitors out of semaphores and you can imagine it's。

it's even easier to make semaphores out of monitors that's a an exercise for you guys。 Well。

you're sitting there。 So。 Okay， going to close this out。 But。 So as we go forward。

The assumption here is that you're going to get better and better at looking at synchronization situations and figuring them out。

You know it's one of these things where I can give you examples。

But it's going to be up to you to sort of retrain your brain into thinking about these。 All right。

But， you know， I think。 If worse comes to worse going to a monitor certainly ought to be the easiest thing to think about。

I haven't had an example in a research。 Project I'm doing where I suggested that somebody is condition variable because they had to put the thread to sleep。

And wake it up later and it turned out that was absolutely the right thing to do。 Very simple。

And these， by the way， are available in a lot of situations。

including in thread packages like Pete threads。 But I wanted to say a little bit about before we sort of close out synchronization entirely。

I wanted to say a little bit about。 Support for synchronization in languages。

So if you go to the thread， you'll see I should put a slide in here on that。

There are P thread new Texas and there are P thread condition variables。 That are implemented。

So if you just do a man on the P thread packages， you'll see those。

So if you're working with P thread， you'll you'll absolutely be able to synchronize with monitors and semaphores。

Those are available。 Okay。 So， see is a little bit of a crazy language， though。 All right。

How many people think C is a crazy language。 Okay。

The worst part about C is it lets you do all sorts of bad things。 Okay， that you should never do。

All right。 And the worst thing you can do with C is you can have dangling memory pointers that you forget about or you free something twice or there's a lot of bad things there。

But that's not what we're going to talk about here。 Here。

if you have some code that acquires a lock and there's an exception inside of the code。

you need to check every exception path and release the lock before returning from that procedure。

Because if you don't do that， we'll be leaving this here。 If you don't do that。

then you can either easily have an exception and return out of the code to the calling function and the lock is still kept and there's nobody to ever release it。

See that， because normal， normal code is you acquire you do some stuff you release。

But if there's an exception， you need to make sure to release the lock。 Okay。

and this makes see really messy for locking。 You just got to do it。

What even makes it more messy is the set jump jump long jump idea。

How many of you have run into set jump and long jump before anybody。 You're lucky。

Let me tell you what set jump and long jump are these are a poor man's version of exceptions。

which are here's a stack。 You start with procedure A and then you go to procedure B and you call something called set jump。

which gives you a handle that'll let you throw out a bunch of the stack and return to the place where you called set jump。

So it's like an exception。 So here we are， we go to C， we acquire the lock， we go to D。

There's an error or something in E that calls long jump。

it'll throw all this stack out and go back up there without acquiring the lock。

or without releasing the lock。 And so， there we go。 Bad news。 Okay。 Now。

fortunately set jump and long jump are something you use a lot these days。

but I'm just warning you that and see this is just messy。 Okay。 And then maybe you could use go to。

How many people have been told that never use go to。 Okay。

under pain of losing your first born or something to to the sea troll。 I mean， this is， you know。

so this is not great。 When you get to anything more powerful than see though it turns out it's good。

For instance， in C you still got to make sure that if if food has an exception， it'll get thrown。

And you can catch it， which means that you want to do something like this at minimum where you say I'm going to try to do who if there's an exception I released a lot。

Notice how that's looks like the C code， but this is a lot cleaner because all exceptions will come through that one path。

Okay。 Now， if you're a C plus plus person in the audience， you'll say， but wait a minute。

That's not a good way to do it。 There's an even better way。 Okay， and you guys。

I encourage you to Google lock guard。 Okay， so what this means is here we have a procedure。

That's going to increment this global variable cleanly no matter who how many people try to do it。

And what happens here is when you allocate the lock。

So this is actually on this is a local variable。 Here you allocate a lock guard and it locks the global mutex。

And the point of this is it doesn't matter how safe increment exits under any circumstances whatsoever if safe increment exit that lock will get freed。

Okay， so if you're ever doing locking and C plus plus this or some of its variants are the cleanest。

Okay， because this particular type of thing this lock guard。 Basically。

anytime it finally goes out of scope， it pulls the path that basically unlocks。 Okay。 Python。 Well。

you could allocate a lock and then you can say with lock to stop and what that means is no matter how that with statement exits。

The lock will be free。 That's almost identical to what I just showed you with C plus plus。 Java。

your favorite， right。 They， I don't know， they still do Java and 61 be good。

I haven't taught that in a while。 Actually， I haven't taught that when I。

I'm not sure if you're not going to get things about it， but if you look here。

you can say public synchronized。 And what that means is that every object has an implicit monitor built in that includes a lock and a condition variable。

And so as a result， you can say this particular method get balanced。

You remember when we talked about the bank account is synchronized。

And this get balance will ever get run by a thread is if it first acquires the objects lock and then it'll go in there and let you go。

Okay， so just by saying the word synchronize。 We use the law automatically。

How's that for a lot simpler than the way we introduced this a few lectures ago。 Okay。

and furthermore， Java has， like I said， a single condition variable。

You can write every object and so you can do weight。

and you can also do a weight that has a timeout。 And you can notify and notify all of those who are the full and await and broadcast or have signal and broadcast。

I mean。 And so that's how you do it in Java。 So Java actually has monitors built into the language。

which is kind of cool。 Okay。 All right， I think we're gonna we're gonna let we're gonna let synchronization rest for a little bit unless people have some questions。

Go ahead。 Let's see。 Make sure there's nobody here。 Okay， anybody else have any questions。 Oh。

in the back。 No， that was a stretch。 Okay。 So， I've been a strivia as easy today。

Unlatt like last week where you had an exam and a design review。

and had to solve the halting problem standing on your head drinking coffee。

This is a relatively minor week。 And so I don't think there's any major deadlines。

although you got to keep moving on stuff。 I took a glance at the schedule。 And so。

I'm waiting the midterm。 I was told to say that there's anywhere between 80% and 85% done。

And of course I want to inform you that。 You know。

75% of all statistics are made up so you know you can use that as a。 However you want to。

I'm not sure if anybody has any administrative， it's trivia today。

So I figured we start a new topic if that's okay with y'all。

We can put our minds to rest about the midterm there's solutions that are posted。

There is a thread for asking questions about the solutions and I'm a little behind on answering some of them。

but I will make sure they get answered。 Should we move forward。 Forward。 Alright， so I want to say。

here's a picture。 I think I even had this picture in the slides for the first day。

which is this this loop of what what it is in operating system does it sort of says if there's a ready thread。

If there are any ready threads you pick one of them， and you run it。

And otherwise you run an idle thread and periodically you loop。 Okay， that's。

I think the way I said well this is the whole operating system we're done let's do our final right。

What we want to do today is we want to start discussing scheduling which is really what is the select red thing。

There's another picture I showed you here about， you know， scheduling。

which says there's a ready queue， which is a set of all threads that the CPU is ready to run。

And really the question is how is the OS to decide which thing on the ready queue is going to be the one that goes next。

Okay， and so scheduling is really deciding which threads to give access to resources for moment to moment。

And by the way， for the next several lectures， we'll talk about giving access to CPU time。

but scheduling is so much more。 Okay， we， you can talk about scheduling this bandwidth。

you can talk about scheduling， I/O resources can talk about scheduling memory。

There's lots of things you can schedule， but we're going to just schedule the CPU for the moment。

because we're really trying to figure out what happens， between the ready queue and the CPU。

All right， that's our goal for the next couple of lectures。 And I'm happy to admit， by the way。

that Anthony is actually back so he may actually get to do a couple of these lectures too so we'll get to see somebody else but for today。

other than me， but for the day。

Scheduling is all about cues。 Okay， and cues I'm sure are your favorite things。 Okay。

this is clearly from the before times because they're not all wearing masks。

and they're not six feet apart。 Yes， soon maybe okay。

What are some assumptions about scheduling okay the first assumption is some of the assumptions really came up from the 70s so scheduling really became a big deal in the 70s。

And it was a big area of research。 Notice that we only have three lectures on it。

but it was a really a major area of research。 And many of the implicit assumptions for CPU scheduling actually came from back then。

And they are sort of like well there's one program per user。

One thread per program programs are independent。 Okay， so that's a little bit。

You know that's a very old school way of thinking of things is also kind of what happens when you have a bunch of different users sharing the same machine so it's kind of the main frame look at things。

Okay， but a lot of the work that was done in the 70s is still happily used today。

Clearly these particular ideas here are unrealistic but they do simplify the problem in a way that can be solved。

So the for the very first lecture here we're going to kind of start with this idea in our background to one program per user one program program through independent。

And then we're going to slowly add in more complexity to our processes as we go forward to get more interesting scheduling。

Okay。 And so the high level goal just to remind you here。

this is you know our favorite diagram again from the first day of the printer inverse colors magenta cyan and yellow。

Those represent different threads we're going to all decide to how to schedule those on a CPU one CPU。

And notice how now they're all have different amounts of CPU time because they're longer shorter whatever。

How does the scheduler decide。 Okay。 All right， so far so easy questions。 Yes。 Ah， what is a user。

So the user。 Is an instance of a principle or somebody who has。

Resource is allocated to them the simplest thing you could think of as a login right you log in your user。

The CPU treats you as with your with your user ID。 But as we get a little bit further in the term。

it can be more more general than that it can be like I said if you have a public private key pair it could be a principle in this in the security sense but for now think of a login ID for now。

Okay。 Another question here is process scheduling more of an implicit thing by the scheduler like the scheduler who has switched threads and those might be in different processes。

So up to for now we're not actually going to talk about。

Or limit ourselves to worrying about which threads are in which processes。 Okay。

we got a bunch of threads they all need CPU time。 And in answer to this question。

you could imagine for instance that you might work your way through all the threads in a process and then switch to another process。

You could imagine。 I can imagine almost anything right。 A large。

for a Latino or something right you can imagine almost anything。

But what's interesting there since it was brought up is if you've got processes with 100 threads and another process with one thread。

What's fair。 Is it fair to give equal time to 100 threads in process A and one threaded process B so that they're really are 101 threads and each of them get one over 101 of the time。

Or， what it makes sense to give half of the time to process A and have to be and then process A divides all their time up to their 100 threads。

Okay， so what is fair。 That's going to be a problem here that we have to solve。 Okay。

So one assumption that was in a lot of these earlier scheduling papers and is a good one is basically this idea of CPU bursts。

where if we look at how long does a thread run。 Oh yeah， go ahead。 Is program the same as process。

Well， I'm going to say yes for now。 Imagine you know about for right so program could have a bunch of processes and then in that case program and process are not quite the same thing but we can only so throw so much complexity in one day so let's stick with one process per program just for now。

But if you notice， when you have a thread and it's circling between the CPU and the various weight cues。

You could say how long does it run on the CPU before it's put the sleep。

So if you have a timer going off and it computes forever。

Then what you'll see is you'll just see threads maybe cycling between CPU and weight cue。

And they all have exactly the same amount of time they get to compute before they go to sleep。

And so， we actually put IO into the picture， then you can imagine that some number of those threads are waiting are only woken up because of a key stroke on a keyboard and they run for a little brief free to time and then they go back to sleep on a way to associate with the keyboard。

Okay， so there's a lot of reasons that threads could go to sleep and so if we were to measure this called the CPU burst time which is kind of how long does a thread run before it goes back to sleep again。

So， something like this peak here， where there's a lot of really short bursts and some and a very long tail tail of long ones。

Okay。 And so programs or whatever they are threads we're not going to get too tight up at all of this yet。

So， there's threads run for a period period of time called a burst and then they go back to sleep。

And if we were to measure this think of this as a probability distribution of bursts of threads you see this peak at the low end。

Can anybody give me an idea where that peak at the low end might come from。 Okay。

the duration of a timer interrupt。 No， let me explain why I don't think that's what you're looking for。

So if everybody was bounded by a timer interrupt。 Then there would be a like a delta function at one time right because the。

you know you'd run for 10 milliseconds a timer go off the next guy run for 10 milliseconds。

But we have this distribution that's not like that right it's got some peaks at the low end and a very long tail。

And because there's things with the long tail， you have to suspect that if the timer ever gets involved。

It's interrupting folks way down here。 Right， because they're running for a long time and then they get interrupted。

So why do we think there's a burst down here。 Yeah。 Starting up the process。 All right， maybe。 Yeah。

go ahead。 Okay， I owe you're getting。 Yep， that's pretty good。 Getting closer。 What about I owe。

Yes。 Okay， maybe it's disk access time， although actually that's going to be way the heck out here in a place you can't see on the screen because remember million cycles。

What type of I oh yeah。 Okay。 So， yes， you have to load the program so I'm going to give you a guess here so somebody says actively computing and then waiting for I owe yes。

Point number one。 Why short interactive processing right because you。

you're waiting and you get a key stroke and you process that the letter a。

and then you go back to sleep and then they type a B and you process the letter B and go back to sleep。

So things at the low end here tend to be interactive。 Okay。

there are situations where the program threads are running on behalf of a user and making the user happy by quickly processing some event from the user and then going back to sleep。

Okay， and now if we start including other things like I owe of other sorts。

And we look at this much longer realm， but I think the important part here is if you look at the set of threads out there。

There's a lot of really short bursts and that's because in even back then you have these machines are processing user interactive。

I owe。 Okay。 And so every scheduling decision。 Kind of is about if you've got a whole bunch of threads。

how do you pick the next one。 This shows you if you have a bunch of threads and you run them。

What did they behave yet the scheduling decision is before we run it。

How do we decide which are the ones to get。 Okay。 And what。 You know。

and with time slicing in the timer you probably could be forced to give up the CPU if you're computing pie or something but why can somebody tell me why just processing the threads in BIFO order might not be the best for users。

Yeah， so users have some interactivity they want to have happen。

And if you're busy computing the next million digits of pie。 Maybe you don't care。 Right。

So it might make sense to give priority to the short burst over the long ones right and that's for interactivity。

So scheduling here you can see starts to come into play with how do we make sure that the scheduler makes users happy。

So that's going to be important to us。 So what are some goals that we might have for the scheduling policy。

So one might be we want to minimize the response time。

So this is minimize the elapsed time to do some operation。

So it might be the time to echo a keystroke on in an editor or the time to compile a program。

or maybe with real time tasks which are going to be more topic for next time。

We might want to meet the goals imposed by the world。 Yeah， it is interesting。

It hasn't escaped my notice that there's a lot of Tesla model wise floating around these days you guys see them they're like every other car on the road practically。

But here's a situation where you have cars that are driven by computers。

And you can imagine certain things really have to happen quickly like breaking。 Okay。

so if we go back to this， and we're talking about， you know。

what to prioritize it might be in a real time sense we better prioritize stopping over missing the video that you're not supposed to be watching。

Right。 So real time tasks scheduling starts to get very interesting。 Okay。

and we're going to have to have whole lectures on that include real time in it。

So another is maximizing throughput。 So these， you know。

things have gotten a lot cheaper over the years， but it's still important to maximize the best use of your CPU。

And so maximizing throughput could be important and maximizing throughput and minimizing response time are not necessarily compatible with each other。

Okay， because minimizing response time might mean as soon as a user's responsive thread needs to run。

go ahead and interrupt the current one and run。 That gives you response time minimizing response time。

but maximizing throughput might be never interrupt a computing thread so that it's cash state and all that other stuff gets to be undisturbed and the thing can run at maximum speed。

Right， so minimizing response time maximizing throughput， not quite the same thing。 All right。

And then of course there's this fairness thing which is you should sharing a CPU among users or among different aspects of the system。

So in this case， like in a Tesla users could reflect breaks video playback， you know。

whatever you could， you could divide all these things up。

Those are all different users and we need to have different priorities among them。 Okay。

and so that that little conundrum I gave you earlier about what it means to be fair to the threads in a process with 100 threads is a little bit tricky because you could do fairness by thread or fairness by process or fairness by who knows what else。

Okay。 Good。 I don't want to belabor this point， but any other questions on this so far。

So now you can start to see why scheduling is not just yeah a couple of slides were done。 Right。

because you know you have to decide what's the policy you want。

and then you have to decide how do you build a good scheduler the kids you have policy。 So。

the first type of scheduling is easy and let's talk about this first come for serve or FIFO。

So the idea there is basically a thread goes on one cue。

and it runs until it's done and then you pull the next one and then you pull the next one and then you pull the next one。

right。 And so， there you go。 There's a， there's a FCFS or FIFO Q。 And in early systems。

this was basically meant that one program runs until it's done， including IEL。

So you'd have these huge machines they'd fill a room。 You would submit your job to run overnight。

and they would run them one at a time。 They'd run the first job， then they run the second job。

then they run the third job。 And they would do that to really maximize usage of the hardware to make it work as good as well as possible。

Okay。 Now， we can think of a modern update to first come for service you run until your first runs out。

and then you go to the end of the queue。 Okay。 So this is that there's no timer interrupt here。

This is just run into a bunch of bursts until you do something that requires either IO or you're actually done。

Okay。 And so we could do this with a Gantt chart like this so suppose the processes arrive in order process one。

two， three， and suppose the process one。 As a first time of 24 process two as a first time of three process three as a first time of three。

Then， if I， if they arrive in that order and I process them first come first serve what does that mean it means I serve process one and then process two and then process three。

And so if you look at that， that means if I have one CPU process one runs for 24 time units then process two runs for the next three and process three runs for the next three。

And we can start computing metrics like what's the waiting time for process one zero because it doesn't have to wait。

What's the waiting time for process to 24 because it's got to wait for process one to finish。 Okay。

everybody with me on this。 Okay， and then we can come up with what's the average wait time。

So zero plus 24 plus 27 over three average wait time is 17。

and then average completion time so wait time until you get to start completion time is until you're done。

And so we can compete those two metrics。 Okay， now this is not terribly profound or hopefully not too difficult either unless you can't add and divide which of course that's always a problem we'll have right。

You can imagine that this average waiting time and the average completion time reflects something about goodness of the scheduler。

especially since the average waiting time if you've got a bunch of interactive threads that are waiting to run。

You probably want to keep the waiting time as low as possible to keep your users happy。 Right。

so this is a metric that maybe we need to optimize。 And actually if you look at this。

but it's really unfortunate about this is only because process one arrived first through process two and three after wait so long。

So this particular scheduler is really sensitive to what order things arrived in， you know。

and that's， that's probably not a good thing。 Right。

And so we actually have here what's called the convoy effect。

which is short processes get stuck behind long processes。 Right。

this is also known as the five items or less problem。

And safely right do you think you're going into the five items or less line except that the person with their one item is a is a cart full of 12。

000 items right and so they never worked like there should。 Okay。

so if you look at this convoy effect we could graph this out。 So， we have sort of scheduled task。

Here we have the green one arrives dark green arrives blue was already ready running。

Now green gets the run， you see this so this is the actual scheduled task， these are the cues。

And so， we basically we had blue running green and dark green showed up there run to completion then red shows up。

etc。 And we can start tracing through this but suppose that red that showed up is going to take。

a long time。 Notice how we take red off the queue and started running so light blue is the head of the queue and green shows up and purple shows up and some other color of green forest green shows up and then blue。

And notice how all of these threads showed up in our building up in our queue。 Well， red is running。

Okay， so that's the convoy effect because they're all stuck in a convoy behind red。 Again。

hopefully that's just a graphic。 Example of why maybe first come for search that's terribly great for us。

Okay。 So here's a and here's the other thing to see right if they happen to show up in the other order like P two P three and then P one。

Then we could compute stuff and notice that our average waiting time now is three instead of 17 and our average completion times 13 instead of 27。

So just by reordering， we've got really happy users now are much happier users。 Okay， so。

so the pros and cons of this fight for first come for serve is plus simple。

Minus short jobs stuck behind the long one。 And that's the safe way example。

I guess the positive is your stuck in line to get to read about space aliens。

while you're waiting to check out counter I guess there's something but。 All right。 So。

the question here also is first defined as a period of time with lots of computation activity no burst is the time。

Of from when you start running to when you stop running and then we graph that earlier。 Okay。 Now。

let's do something different。 Okay， go ahead question。 Ah。

so for now let's assume the scheduler is infinitely fast。

So it doesn't have to run very long all that has to happen is when P two finishes at that little sliver of time we asked the scheduler who's next。

And the scheduler says P three。 And if you think about a FIFO queue。

there's not a lot of computing cycles involved in a FIFO queue。 Right。

Now as I mean you just pull the thing off the head of the queue。 Now as we get more interesting。

Our structures are going to get more interesting and you guys are going to have to remember your 61 B so like we could have a heap structure or something like that where we're trying to pull the shortest predicted burst time off the queue but we're not there yet。

So for now let's just assume the scheduler runs in that infinitely small period of time from when we ask it to get something back。

Okay， yeah question。 So for now， remember that all of the mechanism mechanism for putting threads to sleep and waking them up all that's in the kernel。

And that when you go to put a thread to sleep you ask the scheduler will still in the kernel to give me the next thread so all the way cues all that stuff is in the kernel for now。

Okay。 We'll get more interesting at other times but for now everything's in the kernel still。 Okay。

so this， this doesn't seem great。 Okay， so first come first service basically not done in interactive systems at all。

Okay， so what else could we do。 We could do something called round Robin。 So this。

so the problem with the first come first serve scheme is it's potentially bad for short jobs。

Depends crucially on the submit order。 Okay， if you're first in line the supermarket with milk you don't care who's behind you but on the other hand if you're behind somebody you do care who's behind you're in front of right。

or who's in front of you so the round Robin scheme。 Is what we call preemption。 Okay。

Sorry about the robin there but I was， I got a little carried away with clip art at one time so this Robin I。

I'm not subjecting you to this Robin spinning around here so we're good。 All right。

The round Robin scheme often called preemption is very simple。

and we've been talking about this since day one， but you didn't realize it。 It is， you run a thread。

a timer goes off you take the thread off the CPU you put it at the end of the queue and you take the next one and you run it。

Okay， that's called round Robin believe it or not and it's because all of the threads are going around between the ready queue and the CPU。

Okay， and after the quantum expires whatever that is well I say here between 10 and 100 milliseconds that's a pretty standard number for a modern Linux kernel is 10 or 100 milliseconds。

And after the quantum expires the process is preempted and we had the current thing to the end of the queue and we grabbed the one at the head。

So for instance if they're in processes and already Q and the time quantum is Q。

Every process gets one over end of the CPU time just because it gets one end。

And in chunks of it most queue time units。 And so if you think about it no process ever has to wait more than n minus one times queue time。

And why is that well it's just you have to wait for the folks in front of you and then you get to go。

And so we can tune Q down if we wanted to to make things more responsive to make sure that if somebody were an interactive thread they could run quicker。

Okay， and if you notice I have the quanta here as a range between 10 and 100 milliseconds being standard。

I think I mentioned this in a previous lecture let's see if you remember what what is significant about 100 milliseconds and humans。

Hopefully your reaction time is a little faster than that normally。 What else。

but that's your on the right track。 It's when you start getting annoyed so when things feel laggy。

Okay laggyness is certainly at 100 milliseconds they done a lot of studies。

For this okay and you can imagine if there if you're heavily interactive you might want to get down to the 10 millisecond range or whatever。

Okay。 But so performance you can imagine a lot of tuning here so if Q is really long。

Then you almost never have the timer go off and you basically just have first time for a serve again。

Right， because you almost never cut anybody off。 If it's really small。

You're interleaving because you run for， you know。

a few milliseconds and then the next one runs and the next one runs。

And if you really went down to like one， maybe it's like hyper threading except you'd never do that because the software is running this right so this would be all overhead and no computing。

Okay， so Q has got to be large with respect to the context switch time。

Because otherwise the overhead is too high but you want it small enough that interactive jobs don't annoy their users。

So you can see there's a trade off there。 Okay， questions。 So actually。

you can't leave that up there long enough any questions。 So now if you look。

here's an example of round Robin with the time quantum equal to 20。 So process P one。

First time a 53 process P two first time of eight process P three versus the key eight process for 24。

So imagine the quantum is 20， which means we wait 20 units of time before the timer goes off。

So notice if P one starts， it gets to run for 20。 Before it gets killed off restarted using put back on the end of the queue because the first time is over 20 right so we run for at least 20。

And now P two only runs for eight。 Why。 Because the first time is only eight right。

So it's going to end at eight and then P three gets to run for 20 because it's time is at least 68。

Before gets to run for 20。 And then as we work our way through notice that P two is already exited the system。

etc。 And we could， we could go through those one at a time and that might get very agonizingly painful so we won't。

But we could say what is the waiting time for different threads so P one's waiting time is notice it starts out with no waiting time。

But then it has to wait 68 minus 20 units of time right。

And then it also has to wait 112 minus 88 units of time。 So we could see that for P one。

the total amount of time it waits is is 72 here。 And similarly we can compute for all the other ones。

And then the average waiting time is 66 and a quarter and the average completion times 104 and a half。

So that。 You know， those are just numbers， but you can see we can use these metrics to start playing with。

Like as we change the quantum， do we have a better average waiting time or not。 Okay。

and so the brown Robin， the pros are it's better for short jobs by far than first come for serve context switching time adds up for long jobs。

Okay， and here， we're assuming just because it slides in class that there's zero context which time but we all know better。

Right。 So if you switch a lot， you know you're going to add up a bunch of time saving and restoring registers and doing all that sort of stuff。

Okay。 And so， for instance， here we had when we have if we have a quantum of 10。

and we have T one and T two， we see that we get an average response time that's long if we have a shorter quantum。

Notice that our average response time goes down。 Why？ Well。

because we get T one out of the way so T two can run。 Okay， make sense。

Here we have two threads with a quantum of 10。 Well。

the quantum of 10 doesn't affect the two threads because their first times are one。

So the average response times 1。5。 Same with the quantum's one so quantum here doesn't change anything。

Okay， so now you're going to start to say wait， this is very dependent on the threads。 Yes。

unfortunately it is。 Right。 So here。 If our quantum goes from one down to a half。

The average response time goes up。 Why is that because we've gotten to a point where we're switching too much。

It actually makes things a little worse on the average response time front。 Okay。 Now。

you can obviously see。 Mid term questions out of this。 But hopefully you don't get hung up on that。

Try to get some insight here right so。 How do you implement round Robin in the kernel。

I'm going to show you that trade off with you in another slide in a second。 But a five oh Q。

Just the same is with first come first serve， but you preempt the job as soon as the timer goes off。

you take it off of the CPU， put it on the end of the queue and just keep going。 Okay。

Time or interrupt。 So I've been talking about round Robin since the day we started。 Okay。

lecture one round Robin。 So in this ready cue。 Here's the cue we're talking about right there。 Okay。

hopefully not too mysterious。 Project two。 Not there yet。 You get to work on scheduling。

This is a relaxing week。 You work on project one。 But when we get to project two。

you get to work on scheduling。 Okay。 Now， you know， how do you choose the time slice？ Well。

hopefully you see if it's too big。 The response time suffers。 If it's infinite。

you get first come for serve。 Time slice too small。

You're through put suffers and you swap too much。 And so actual choices。 I said again。

we're between 10 and 100 milliseconds。 And， you know， originally in Unix。

they actually had a one second time。 And I have to say。 I wrote papers with multiple email access。

Talking to the same mainframe。 And it was amazing when there were too many users you type a long phrase。

To be or not to be that is the question。 And a second later it would go。

And you get your to be your thought to be that is the question。 So not interactive。 Even slightly。

Okay， try to imagine editing a paper like that。 It was。 Not fun。

So you got a balance short job performance and long job throughput。

So typical time slices 10 milliseconds to 100 milliseconds。

Typical contact switch overhead between point one and one millisecond。 And so roughly。

you could say we're getting about a 1% overhead of switching。 So that's not too bad。

We're not wasting。 More than about a 1% of our cycles doing the switching。 Okay。 Questions。 Good。

Yeah。 Ah， is the time slice always constant or can it change？ Yes。 So。

mostly people leave alone and it's constant。 But you can change it under some circumstances。 So。

it depends on。 It depends on your scheduler and system。 But， you know。

the problem with the problem with the quantum and I'm going to show you another slide just a second here is。

It's a pretty。 Course。 It's a pretty good thing to tune。

It doesn't necessarily give you what you want in terms of really responsive and so on。

It's pretty good。 It's a nice kind of heuristic that works pretty well most of the time。

And so trying to fine tune cue。 It is probably not going to be worth the trouble。 But it's a。

it's an interesting thing to think about。 And in principle， you can。 I'm going to put this up。

I wanted to put this up because。 Let's put a couple more slides up here。 So simple example。

you got 10 jobs each。 Take 100 seconds of CPU time。 Round robin scheduler quantum of one second。

All jobs start the same time。 So you can look at the completion times here with FIFO。

And then you're done in a thousand cycles and again we're assuming that there's no overhead to switching with round robin in one second you're just doing。

you know。 Job one job to job three job for job。 You work your way through and。

That will also end in a thousand because they're both。 You know。

100 times 10 total CPU cycles are needed。 So they both finish at the same time。

but the average response times much worse under round robin here。

And the easy intuition is with FIFO you got some jobs that end really early。

whereas with round robin they all end really late。 So the， the， you know， the。

the average response and final response final completion time are very bad。

And in this round robin case， your cash state keeps getting swapped out so to any。

to the extent that your CPU is doing a nice job trying to get things in cash。

This is kind of working against throughput for you。 Okay。

So here's another slide。 You know， cyan and Fuchsia great colors right so the best for suppose we have threads here P one is 53。

P two is eight P three is 68 P four is 24。 We showed you that earlier。

The best first come first serve is if the shortest one goes first and then we go the next longest and the next longest and the next longest。

And so you can kind of see。 From a wait time standpoint， the best first come first serve。

And then for the average of 31 and a quarter， the worst gives you an average of 83 and a half wait time。

And then from a completion time we get 69 and a half and 121 and three quarters for completion time。

We can say at the quantum is eight。 We can see that we get our average wait time to 57 and a quarter and average completion time to 95 and a half。

So notice that that's between the best and the worst。

And then of course we can put all these other ones in the middle。 And you can see that， you know。

as long as you're kind of in the middle， it mostly works pretty well。

And fine tuning plus or minus is not really going to give you necessarily anything consistent there。

Okay。

Notice also though， P2。 What about P2 P2 is eight。 It's the shortest one。

Notice that P2 has the worst variance in possible scheduling here。 So notice。

if P2 is short because it's an interactive job for a user。

Notice that it has awesome wait time at zero or really bad wait time at 145。 Okay。

so this user is really either really happy or pissed。 And fortunately。

if you kind of get a reasonable quantum there。 Neither right there just they're okay。 Right。

So the shortest job gets the most impact by varying the scheduling。

And the other thing to notice the longest job， like we're computing digits of pie has the least variation because notice。

unless you pick the worst first come first serve when it gets to run first。

It's otherwise basically the same， no matter what your quantum is。 So what is that。

What's the bottom line from this slide the bottom line from this slide is。

You want you don't want to worry as much about the long jobs because the short ones get really impacted by scheduling。

Okay， and the short jobs are your users。 So what that says is really annoyed users are much easier to get than annoyed computations of pie。

Right。 Good。

Now， that's all fight and dandy， except that the problem with this is kind of everything is mostly treated I they're treated identically here right because we。

we basically say we set a timer。

And if the timer goes off and you're still running we put you at the end and we'll run you again later that's the only thing that's going on here and all tasks are equal。

But we can imagine， instead wanting to prioritize tasks and suddenly we've got a priority scheduler。

And you'll get to learn a lot more about this and when you start doing number two of your projects。

And so if you look here， we could have， you know， priority three priority two priority one priorities you're。

Zero queues。 And this now we have an execution plan which is always execute the highest priority runable jobs to completion。

possibly with a round robin and then go to the next priority in the next priority in the next priority。

So notice that now， not only do we have round robin to make sure sort of all the jobs kind of make progress at a given priority level。

but we've now put priorities on them。 So that we can decide that some jobs are more important than others。

Okay， you've all read animal farm， how many people remember animal farm right。 Some。

some animals are more important than others all right so that's what we get out of this priority scheduling。

Okay。 Now， of course the problem with this is going to be choosing who's what priority right picking the priority so that you get whatever effect you want it's going to be tricky。

But， and some problems that are pretty obvious hopefully is that starvation becomes very possible。

If you've got a job stuck at the lowest priority and nothing but higher priority things come in and the low priority one will never run。

Okay。 And so， you could actually end up with something even worse which is a priority inversion。

And this actually took out the Martian Rover。 And maybe I'll make sure we talk about that next time but what happened there was if a low priority job grabs a lock。

And then a high priority job is waiting for the lock。 Okay。

and a middle priority job is running computing pie。 Now you're now you're dead law。

Why is that well the high priority ones trying to sleep。

They're trying to get the lock but sleeping the middle ones running and the low priority one can never run and release the lock。

Okay， and that is a situation that will never resolve itself。 Okay。

And it turned out there was a problem with the Martian Rover just like this。

And where the high priority was was the bus and the low priority was a particular measurement scheme in the middle priority was doing some maintenance of the of the device。

And the only reason they actually managed to get the Rover to do the right thing。

This is one of the original rovers was they were able to reboot it and debug it from earth。

which was pretty fortuitous。 So， so how do we fix problems with priority scheduling well that's going to be an interesting topic for us。

Because we got to start varying the priorities dynamically。

So we start with a given set of priorities but then we move things up or down based on dynamic heuristics。

Okay， and that's how we're going to play with this。 Okay。

so hopefully you're starting to see that scheduling gets more interesting with the moment right or maybe more complicated。

I don't know。 We'll have to talk about that。 So we can ask ourselves what about fairness。

So strict fixed priority scheduling between cues is very unfair。

Okay， this， this is unfair because as long as there are priority three jobs。

none of the lower priority ones get to run。 But maybe that's okay if the priority three jobs are trying to put the brakes on。

Okay。 Now the question I just got in the chat is， is what I'm saying here about priority rearrangement。

meaning that the something with the lowest priority could suddenly become the highest。 Well。

in fact， yes， there's something called priority donation。

where if a high priority thread is trying to grab a lock， but a low priority one has the lock。

All right， what will happen is the high priority one will be able to donate its priority to low priority one so that it can run long enough to release the law。

Okay， and that's just one of many dynamic priority things we're going to come up with。

So， so strict priority scheduling between cues is unfair。

There was an urban legend that's absolutely not true。

but I'll repeat it anyway because it's an urban legend， which was in multi。

They shut down the machine and found a 10 year old job that had been sitting in the queue for 10 years and never run。

Okay， the only thing this serves is to point out that urban legends are ridiculous。

And be a B and be that。 Trying to make it very clear that low priority things might not get to run。

Okay。 So you have to give long running jobs， some fraction of the CPU。

you do strict priority scheduling。 Maybe you won't have a job stuck for 10 years。

but you could have very well have a job that you want to make some progress that never makes progress。

Okay， so this in its purest form is probably not a good plan。 Okay。

but it starts to give us the idea of knobs that we can twist to try to allocate CPU to things that matter in the moment。

Okay。 So the trade off is the fairness gained by hurting the average response time。

So what we do is we give the long running jobs a fraction of the CPU。

then they're really short ones。 Get less CPU and that might be okay。

So how do you implement fairness， you could give each cue some fraction of the CPU。

If you have one long running job and 100 short running ones。 You know， what do you do。

you could increase the priority of jobs that don't get service。 Yes， go ahead。 Ah， so the。

is there a way to decide your priorities。 So the tricky part about that question is。

You think you're doing you come up with a good scheme and invariably it's not a good scheme。 So。

there's lots of ways that people pick priorities。 Okay， and just because I like answering questions。

I'll give you this one。

Assume for a moment that there's 140 priorities。 And the bottom one or the top 100 of them。

the most important ones get chosen based on how frequently an event's going to happen in the bottom 40 get chosen based on what we're talking about。

That's exactly what the Linux scheduler has it has 100 real time priorities。

And the way you choose a priority is the thing that occurs with a higher frequency gets the higher priority。

And so there's a way to assign based on its period you could choose one of the hundreds。

One of the hundred priorities and that's a mathematical choice。 And then the remaining 40。

And then the problem we just talked about， which is you got to choose。

but that's at least one way of assigning priorities that matter。

And I'll talk about that when we talk about real time。 So， you could each。

we could get each queue of some fraction of the CPU。

And then we could increase priority of jobs that don't get service。

So if a job is running for a very long time and it's not getting any service。

then you could slowly up its priority to give it more service。 Okay， that's kind of dynamic。

But I want to close with this idea of what if we knew the future instead。

Could we come up with the best first come first serve because remember。

first come first serve is only bad some of the time where it's really bad。

But sometimes it's really good。 Right， a really good first come first serve is what we manage to have the shortest jobs first。

That's great。 Right。 But can anybody tell me why it's hard to do。 No， right。

you would have to do a good job predicting。 So instead， in the last couple minutes of the class。

what I want to do is， what if you knew the future。

So I'm not going to tell you how to know the future yet。

We'll do that next time and you guys can get your stock trading accounts out and stuff but。

Suppose we actually knew。 Okay， then we could get an algorithm。

an algorithm we're going to call the shortest remaining time first， which is when。

when you've got a cue and you got to pick the next one you just grab the one。

You just grab the one who has the shortest remaining part portion of their birth， and you run them。

Shortest remaining time first and there's actually a， a shortest job first。

which is the non preemptive version but let's just talk about shortest remaining time first。 And。

and we can apply it to the whole program or to birth or whatever but if we knew the future。

Then we could do this SRTF and it turns out that SRTF which again it's， we look at the cue。

I picked the one with the shortest runtime left and I run it has the absolute best minimal average response time。

So if we could somehow figure out the future we could do that。 Okay， and it's provably optimal。

Okay， to the extent that provably optimal involves predicting the future。

So if you compare SRTF with first come first serve， for instance。

what if all the jobs are the same link。 Well SRTF just becomes the same as first come first serve why 10 jobs that are equal link。

They're all the same like you pick one， it starts running。

it's no longer ever going to get preempted because it's now the shortest one left right so it runs the completion next next。

Okay， on the other hand if the jobs have the varying link。

the shortest remaining time first just make sure that short jobs always go first。 Okay。

and here's a benefit。 So if you have three jobs we have a and b are really long so they run for a week。

See has to run for a very short period of time because it's doing something like copying data off a disk。

So it computes what the next data get off the disk is that it does the disk time and then it computes the next thing。

And so to get maximal behavior。 What I'm going to want to do is run this thing at extraordinarily high priority for the brief compute and then I send things out to disk and I can run something else。

So the only way that this job gets maximum bandwidth out of the disk is if we're always running the short little compute type thing at highest priority。

Okay， and these guys in the background they're going to compute for a week anyway so they don't care if we interrupt them。

Okay， so with first come first serve， if a or b gets to run， see is just toast。 Right。

it will just not work because you got to wait a week。 Okay。

and you don't copy things off of the disk。 So round Robin。 Well with round Robin。

you kind of get this right you run see for a very short period of time。

and then it does its disk access。 And then it gets to run for say 100 milliseconds and be for 100 milliseconds and then see runs for a very short period of time。

Okay， and if you look at this previous slide here。

We want to see actually to run for one millisecond and nine milliseconds at this time。

So it's only with one millisecond and nine milliseconds at this time that we get 100% of the I/O。

And so here， our disc utilization is now nine out of 201 it's only 4。5%。 Okay， so this is bad。

If we round Robin it， we waste a huge amount of time。

We can get the disc utilization back up to close to 90%。 With SRTF。

we can get it to be exactly 90% which is the best we can do。

So I'm going to close there for now we're going to pick up this next time。

But and we're going to take that prediction of the future and we're going to figure out how to do that。

But round Robin's scheduling is give each thread a small amount of the CPU time when it executes cycle between all the threads shortest job first。

It's going to be run whatever job has the least amount of computation to do and do that somehow by predicting the future。

And we're going to turn all that into a multi level feedback scheduler which gives us somewhat of a prediction of the future。

All right。 Have a great rest of your Tuesday and we'll probably see you on Thursday。 Ciao。

[BLANK_AUDIO]。