操作系统学习(一)-- 从发展史理解操作系统设计需求
这是操作系统系列第 1 篇。
尽管操作系统发展史不是研究操作系统的重点,但是在这一发展过程中,衍生出了许许多多与操作系统相关的重要概念,如果知道这些概念出现在怎样的背景下,以及产生的原因,在后期学习中就不会觉得一些概念出现的比较突兀。除此之外,了解操作系统的发展史,理解设计需求,有助于我们站在计算机的角度思考问题。
ENIAC 与串行处理
计算机的发展可以追溯到 1946 年,世界上第一台通用计算机「ENIAC」 诞生在这一年的 2 月14 日(这天正好是情人节)。
图为 ENIAC
> ENIAC 长 30.48 米,宽 6 米,高 2.4 米,占地面积约 170 平方米,30 个操作台,重达 30 英吨,耗电量 150 千瓦,造价 48 万美元。
从这一年一直到 20 世纪 50 年代中期,操作系统是不存在的。毕竟那时候还没有操作系统这个概念。程序员要是想要运行什么程序,得把机器代码用打孔机打在纸带上(这不仅是个智力活,还是个要细心的活儿,打错一个孔你就得重来。想象一下,让你写一篇文章,不用退格键,更不能从中间插入。。。当时的程序员太难了),然后通过输入设备,比如纸带阅读机,载入计算机。计算机就按照步骤一步步运行下去。运行完毕,就把结果打印出来。
PS:这十几年间,编程语言也有很大的发展,这一阶段后期就已经有高级语言——FORTRAN 了。编译,链接,函数库这些概念也已经实现。所以这一时间段的计算机不是你想象的那么落后!
这个时期,用户如果有上机需求,就要提前预约一个时间段,然后才能去上机(往机器里放纸带和控制机器的活也是他们自己来干。当个程序员你还得和硬件打交道)。这样的模式下,问题出现了:
- 如果用户申请了 1 个小时,但他的任务只用 35 分钟就运行完了,那多出来的 25 分钟就这么被浪费掉了。
- 如果一个小时到了,用户的程序还没运行完,这个程序就会被强制停止——这相当于浪费了整整一个小时的计算资源。但延长时间是不可能的,后边还有人排队呢,而且万一是你的程序死循环了咋办。
简单批处理系统
在计算资源匮乏的当时,上面那种串行处理造成了巨大的资源浪费,令科学家们难以接受——必须要提高计算机的利用率。
于是,批处理系统诞生了。
图为 IBM 7090,其上运行着最为著名的批处理系统 IBSYS 。这也是世界上第一款全晶体管计算机
批处理系统的中心思想就是用一个称为监控程序(monitor)的软件。刚刚提到了,串行处理需要用户自己去访问机器,时间段是固定的,但现在他们只需要把作业提交给计算机操作员,操作员会把这些作业按顺序组织成一批,然后把整个批作业放在输入设备上,供监控程序使用。
监控程序已经有点操作系统的意思了,它的的工作过程很好理解:
-
大部分监控程序总是常驻内存,这部分称为常驻监控程序(resident monitor)。
-
一开始,监控程序掌握了计算机的控制权(废话,这时候用户作业还没加载进来呢),它会从输入设备中读取一个作业,经过读入以后,作业就被放置在了用户程序区域,并且获得控制权。当作业完成后,控制权将再次返回给监控程序。
有了监控程序后,计算机的利用率提升了——一道作业完成后立马就会开始下一道作业,没有任何空闲时间,也很少出现作业没完成就被终止的情况(基本上解决了串行处理的问题)。
监控程序的正确运行是依赖于硬件的,在这个时期,为了系统的可靠性,计算机厂商为计算机提供了几样重要的功能:
- 内存保护:这一点很好理解,监控程序的内存空间不能被用户程序随意更改——不管是有意还是无意。*不过当时黑客这一群体还没有发展,毕竟计算机又少又贵,不可能「飞入寻常百姓家」。*一旦硬件检测到有用户程序试图使坏,就会将控制权直接转移给监控程序,取消这个作业。
- 定时器:这项功能是为了防止一个作业独占系统,作业接管控制权后定时器自动打开。如果定时器时间到了而作业未运行完,程序会被杀掉。
- 特权指令:有的机器指令会被设置成特权指令(比如 I/O 指令),只能由监控程序执行。用户程序是不能直接使用这些指令的。当然用户程序可以请求监控程序为自己执行这个操作。特权指令就是为了限制用户程序的「权力」而设置的,毕竟老板和员工不可能有一样的话语权。
监控程序的内存布局,蓝色部分就是受保护的内存区域
这几种功能里,内存保护和特权指令引入了操作模式的概念,我们知道,现代操作系统中依然保留这两种功能——足以见得他们的地位。
简单批处理系统已经具备了基本的任务调度能力,但它仍有很大的改进空间。虽然简单批处理系统为机器提供了一个自动作业序列,但处理器经常还是空闲的,因为 I/O 设备相对于处理器的速度要慢很多,处理器需要 I/O 操作完成后才能接着干活。
举个例子:
CPU 利用率 = 1/31 = 3.2%
CPU 的利用率太低了。有什么办法解决这个问题呢?
多道批处理系统
IBM System360,搭载了多道批处理操作系统 OS/360,公认的划时代操作系统
我们刚刚说了,利用率低的主要原因就是 CPU 需要等待 I/O 操作,那我们让 CPU 忙起来不就可以了?
多道批处理系统就是让 CPU 忙起来的秘诀。方法听起来很简单——在内存里多放几道用户程序,一旦有一个作业需要等待 I/O ,就立刻切换另一个可能不需要等待 I/O 的作业。这种处理,称为多道程序设计(multiprogramming)或多任务处理(multitasking)。
我们来看看这种方法是怎么提高 CPU 利用率的:
-
图 a :仅有程序 A 在运行
-
图 b :内存上有用户程序 A 和 B ,当 A 在等待 I/O 操作时,B 就开始运行。(为方便理解,我们假设 A, B 两程序竞争的 IO 资源是不一样的)
-
图 c :用户程序 A,B,C 同时存储在内存上。
我们可以直观的看到,在同样的时间内,CPU 运行时间大大提升,满足了我们的预期。
像简单批处理系统一样,多道程序批处理系统必须依赖于某些计算机硬件功能。其中最显著的功能就是支持 I/O 中断(Interrupt)和直接存储器访问(Direct Memory Access,DMA)。(DMA 也需要中断的支持)
中断这个词,第一次听会感觉有点玄乎,如果翻译成「打断」感觉会好理解一点(就是不大好听)。当一个作业开始进行 I/O 操作时,CPU 就会切换到另一项作业,那操作系统怎么知道这个 I/O 操作什么时候结束呢?
答案就是 I/O 中断,在 I/O 操作结束后,DMA 模块(哪种模块具体取决于系统实现)就会向 CPU 发送一个信号,CPU 就必须停下当前的事情去处理这个信号,在多道批处理系统里表现为控制权被转移到操作系统的中断处理程序。这个过程,就是 I/O 设备打断(Interrupt)了 CPU 手头上的事情,转而去做另一件事。
所以说中断是操作系统完成各种复杂操作的前提。
多道批处理系统显然比他的前辈们复杂多了,由这个操作系统,又引申出来了几个比较有意思的话题:
- 作业管理:内存的空间是有限的,意味着一次性载入到内存的程序数量也是有限的,那么怎样从备选作业里选择合适的作业加载进内存就是一个问题,这就是就是作业管理。
- 内存管理:选择了作业,就需要为作业分配空间,那从空闲区的哪一部分为作业划空间就是内存管理需要解决的事情。
- 进程调度:进程,就是进行中的程序,一般我们把加载进内存的作业称为进程,以和未加载的作业区分。进程调度,就是当需要进行进程切换时,通过某一种算法从进程队列中取出合适的进程,获得 CPU 的执行。
到了现代,因为内存容量的提升,很少出现有作业需要在后台排队的情况,所以作业管理以后只会花少量笔墨来介绍。但内存管理和进程调度将是我们以后学习的重点。
分时系统
UNIX 就是最为著名的分时操作系统
多道批处理系统可以说是现代操作系统的雏形了,它处理批作业时对处理器的利用率也比较令人满意,但面对多个交互作业,多道批处理系统就显得力不从心了。
交互作业的出现很好理解,毕竟我们现在几乎所有应用程序都是交互式的,你滑动屏幕,这篇文章就会上下滑动,点一个分享,就会出现各种选项,等等等等。
在交互作业中,难免需要等待用户做出操作,但又不可能让处理器停下来等你一个人,毕竟很多人都在用同一台计算机,因此分时系统应运而生。
顾名思义,分时系统就是 n 个用户作业,操作系统控制每个用户程序以很短的时间为单位交替执行。因为人的反应相对机器要慢很多,所以如果控制得当,你会感觉自己是独占了这一台计算机一样。
多提一句,分时系统切换进程靠的就是我们在批处理系统中强调的中断,不一样的是,这里的中断是时钟中断——一到时间就向 CPU 发出中断信号。
如果把多个用户运行的交互程序,看做一个用户运行的多个交互程序,像我们现在使用个人计算机一样,就很容易理解现代操作系统了:
- 多个进程共用一个处理器,每个进程分得一个时间片,而在计算机面前的你看来,好像多个进程是并行的。
- 某进程进行 I/O 操作会被操作系统阻塞,在阻塞队列等待 I/O 操作结束,才能有机会使用 CPU。
- 多个进程在内存上存储,操作系统需要防止进程向其他进程的内存空间写入信息。尤其要保护操作系统自身的内存空间。
- 用户程序运行在用户态,无权使用特权指令,需要向操作系统提出请求。
讲到这,我们已经了解了操作系统的发展,事实上,还有一些其他的操作系统,比如实时操作系统,网络操作系统,分布式操作系统等等,但这些操作系统与我们生活相关性不大(实时操作系统对嵌入式来说还是很重要的),所以在此文略过,有兴趣的可以查阅相关资料。
希望在阅读完这篇文章之后,你能够对操作系统的设计理念有一个简单的印象,如果本文引起了你对操作系统的兴趣,那就再好不过了。
感谢你的阅读,我们后会有期!
声明:原创文章,未经授权,禁止转载
低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
Scala implicit 隐式转换安全驾驶指南
这篇短文将结合实例对隐式转换的各种场景进行解释和总结,希望看完的人能够安全驶过隐式转换这个大坑。 隐式转换函数 隐式转换函数有两种作用场景。 1 转换为期望类型:就是指一旦编译器看到X,但需要Y,就会检查从X到Y的隐式转换函数。 2 转换方法的调用者:简单来说,如obj.f(),如果obj对象没有f方法,则尝试将obj转换为拥有f方法的类型。 object ImpFunction extends App { class Dog(val name: String) { def bark(): Unit = println(s"$name say: Wang !") } implicit def double2int(d: Double): Int = d.toInt implicit def string2Dog(s: String): Dog = new Dog(s) val f: Int = 1.1 //转换为期望类型,1.1通过double2int转成了Int类型 println(f) "Teddy".bark() // 转换方法的调用者,字符串通过string2Dog转成了Dog...
- 下一篇
Spring Boot 2.x基础教程:使用Swagger2构建强大的API文档
随着前后端分离架构和微服务架构的流行,我们使用Spring Boot来构建RESTful API项目的场景越来越多。通常我们的一个RESTful API就有可能要服务于多个不同的开发人员或开发团队:IOS开发、Android开发、Web开发甚至其他的后端服务等。为了减少与其他团队平时开发期间的频繁沟通成本,传统做法就是创建一份RESTful API文档来记录所有接口细节,然而这样的做法有以下几个问题: 由于接口众多,并且细节复杂(需要考虑不同的HTTP请求类型、HTTP头部信息、HTTP请求内容等),高质量地创建这份文档本身就是件非常吃力的事,下游的抱怨声不绝于耳。 随着时间推移,不断修改接口实现的时候都必须同步修改接口文档,而文档与代码又处于两个不同的媒介,除非有严格的管理机制,不然很容易导致不一致现象。 为了解决上面这样的问题,本文将介绍RESTful API的重磅好伙伴Swagger2,它可以轻松的整合到Spring Boot中,并与Spring MVC程序配合组织出强大RESTful API文档。它既可以减少我们创建文档的工作量,同时说明内容又整合入实现代码中,让维护文档和修改...
相关文章
文章评论
共有0条评论来说两句吧...
文章二维码
点击排行
-
Docker使用Oracle官方镜像安装(12C,18C,19C)
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- CentOS8编译安装MySQL8.0.19
- Docker快速安装Oracle11G,搭建oracle11g学习环境
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- MySQL8.0.19开启GTID主从同步CentOS8
- CentOS7,8上快速安装Gitea,搭建Git服务器
- Jdk安装(Linux,MacOS,Windows),包含三大操作系统的最全安装
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
推荐阅读
最新文章
- SpringBoot2配置默认Tomcat设置,开启更多高级功能
- Docker使用Oracle官方镜像安装(12C,18C,19C)
- 设置Eclipse缩进为4个空格,增强代码规范
- Mario游戏-低调大师作品
- MySQL8.0.19开启GTID主从同步CentOS8
- Windows10,CentOS7,CentOS8安装MongoDB4.0.16
- SpringBoot2编写第一个Controller,响应你的http请求并返回结果
- CentOS8编译安装MySQL8.0.19
- Springboot2将连接池hikari替换为druid,体验最强大的数据库连接池
- SpringBoot2整合Redis,开启缓存,提高访问速度