风集 樱之章 · 一
We seleperate the os into 3 easy peice. That's really awesome opinion from someone.
The first is virtualization.
layered model from OS: decouple
Image that you are constructing a building. With the improvement of your building skills and experience. A great ideas occurs that you need to break the building into multi-layers. This idea comes up so easily and naturally the first time I build an enormous software system. And nowadays, That project becomes such an easy piece for me that I can write it from the very beginning directly to the end without a coffee break. But the basic ideas behind the toy building affect me throughout my program career. In the software industry, we called it decouple, whether it is vertical or horizontal, this concept is tough, isn't it? But the basic idea is really simple and practical, it's complex, so I divide it, manage every little piece independently.
And OS is built with this practical idea. It abstract the basic material devices into a new layer -- what I mean is what you can see from your Iphone or PC. It's quiet easy to run a netease music program here, you can just tap the icon, and everything seems to be ok. Therefore, this is just the thing an OS do -- I call it divide the complex system to multi-layers, so the complexity decreases and life becomes more easier.
(by the way, you use this idea all the situations, from scalable microservice system to big scale online machine learning system).
But the problem is how can I implement a operating system so that I don't need to manage the keyboard, the disk, and something like CPU directly?
We have the basic idea and architect now, the next step is realize our idea to a project.
Process as a virtualization: What the fuck is a Process!?
The basic idea os computer itself is really simple, just run a piece of code segement and everything seem to be in the right way.
So how can we describe a running code segement? Task? job? Or we define it as a whole new concept called a process. So if you need to stop the process and continue tomorrow (image that you watch a film and a pretty girl give you a call to have a meeting with her, you make the right choice and wanna continue to watch the film the next day. the Real OS looks a bit different, but this sample still make sense). We need a "process" to represent and save where we paused, in another words, we need to use process to save the state of running code(or more native - computation). The process provide some more function, it becomes the basic execute unit in a computer now. And if you want, you can provide more function to a process.
Complex Concurrency Pattern: Multi-Thread, Asynchronous models and what the Real World looks like...
Why we need concurrency?
Physics is such a cool and execting domain that describe the rules of the material world, we humans use mathematics and concluded formulas to compute the specific situation, and as a result we can predict and understand the world more accurately. But mathematics is a tough guy, and worse, we all have to study it xD. The same terrible thing like this is the real world, it's complex, shows diversity, change all the time and things happens at the same time. When we try to describe the world, we have to simplify it with some simple models, the most common idea is object-oriented programming, it's even become a pattern. When the speed of CPU becomes faster and faster, multi-task seems to be a must to meet the user's requirements. If you need to take 2 hours, or 2 days to run a task. Multi-task seems to be unnecessary, but if it only take us 0.01 second to finish a task. Multi-task is never more useful, and the real world itself is concurrent. You take a fucking useless politic course and read you wechat moments, and the teacher speak out bullshit all the time. see? That happens at the same time. But process is our weapons to simplify the mess tasks sea. Before I learn OS textbook, I have met some concept like thread, async, if you search this keyword, the most articles that explain them are really terrible. It's sheer waste of time to read this articles, but you have to read these fucking shit.
Life is hard.
How to realize a complex concurrent project?
However, ideas behind computer is really simple, just meet problems, solve it. Assuming that you are waiting to purchase food in a hot resturant, and the manager of resturant find the waiting crow is long. So he decide to add a new casher to sell food, but he do not add the cook because the cook act fastly. Thread is something similar to this model. That's
it is stupid easy, isn't it? Even my 10 years old baby can understand how to write code to solve concurrent problem. When I told my ex-girlfriend I will teach my 10 years old kit to program, she though I'm crazy...
How can that little kit understand such a complex thing like Multi-Thread/Async? And the asynchronous model is even more easy -- you don't need to look at the cashier stupidly all the time, do you? Most of us will talk to friends, or read message in phone to kill the time when wait. Asynchronous model says, if computer don't want to wait to download a film, just do something else. because the downloading is a IO behavior, not computation, so the CPU is just wait and sleep, it has no Tik Tok and no emotion, so let CPU do something else is a better choice. That's all about async and thread model. And as a result we build a high-performance software.
Now, we use these two concepts in our cool application in reality - a mobile ticket-seller application server. we have a process running this sever program, this server program is just like the qq music you double clicked in your PC, or Iphone. And the users want to buy ticket. And the rule is that we don't wait and solve concurrency problems because we are cool, we write high performance code!
at the very beginning, we write this:
I'm server
when user ask me for ticket:
return a ticket;
but we need to be cool, we need multi-thread, so the code becomes:
define server
when user ask me for ticket:
return a ticket;
I'm manager (process)
start (thread1) server connect to our tickets package;
start (thread2) server connect to our tickets package;
// two thread share the same resource, especially tickets store in memory.
Now we have two "cashier" to sell tickets~, and if you choose the async version, assume that you return a video:
I'm server
when user ask me for something:
if want video:
read a 200Mb video.
jump to the next ask(don't wait, let CPU handle the next ask), inform me if read video finished.
when read video finished:
return video;
else want ticket:
return a ticket;
Lock, Competition, Synchronous area and other problems occur in the multi-thread model.
To be continue.
最后,这是《艾集》,一个二十多岁的普通人记录自己所思所想的自娱自乐,并向关心自己的人展示自己。
网友评论