NJUSE-OS2025 补充知识

type

status

date

slug

summary

操作系统概念

OS是计算机系统的公共软件基础设施, 所有应用程序共用OS服务, 且OS内核是反应式reactive机制(即中断驱动的).

“脱机控制”和”联机控制/交互控制”是一组相对概念, “脱机”指用户输入程序后脱离控制(如批处理系统).

作业控制语言(脱机)/操作控制命令(联机)

系统层次结构视图

分时/实时操作系统

分时操作系统和实时操作系统是两种不同类型的操作系统, 它们针对不同的应用场景设计, 具有不同的特性和目标. 以下是对它们的介绍:

分时操作系统(Time-Sharing Operating System)

定义:

分时操作系统是一种允许多个用户(或任务)通过终端共享计算机资源的操作系统. 它通过快速切换CPU的使用权, 使每个用户感觉自己独占系统.

主要特点:

多用户支持: 允许多个用户同时在线交互.

快速响应: 每个用户都能在较短时间内获得系统响应(通常在几百毫秒以内).

时间片轮转: 系统按时间片分配CPU, 轮流为各任务服务.

公平性: 系统尽力确保所有用户或任务都能获得均等的资源使用机会.

应用场景:

多用户系统(如早期的Unix系统)

交互式开发环境

教学或科研系统

实时操作系统(Real-Time Operating System, RTOS)

定义:

实时操作系统是一种能在严格时间限制内完成任务的操作系统. 它的关键在于任务的确定性, 而不仅仅是速度.

主要特点:

确定性: 系统行为在时间上是可预测的, 响应时间是有上限的.

高可靠性: 通常用于对安全性、可靠性要求极高的系统.

任务优先级管理: 支持基于优先级的任务调度, 实时任务优先.

抢占式调度: 高优先级任务可以随时打断低优先级任务.

实时系统分类:

硬实时系统: 任务必须在截止时间之前完成, 否则后果严重(如航天器控制).

软实时系统: 尽量满足时限, 偶尔失败可接受(如视频播放).

应用场景:

工业控制系统(如PLC)

航空航天系统

汽车电子控制系统(如ABS)

医疗设备

总结对比:

特性	分时操作系统	实时操作系统
核心目标	多用户交互、公平性	时间确定性、响应及时
响应时间	一般在毫秒级别	严格时间约束(微秒到毫秒)
应用领域	教育、科研、办公系统	工业控制、嵌入式、航天等
调度方式	时间片轮转	基于优先级的抢占调度

批处理操作系统(Batch Operating System)

一种早期的操作系统类型, 主要用于自动顺序地执行一批作业, 用户将任务提交后无需干预, 系统自动完成任务的处理.

定义

批处理操作系统是指:

把一批需要执行的作业集中起来
按照一定顺序依次自动处理

在批处理操作系统中, 为了让系统知道如何处理一个作业, 用户必须提供详细的说明信息. 这些说明通常通过作业控制语言(Job Control Language, JCL)和作业说明书来表达.

相关设施

作业控制语言(JCL)

定义:

作业控制语言是用户与批处理操作系统之间的接口语言, 用于描述作业的控制信息, 如要执行的程序、所需资源、输入输出文件等.

主要功能:

指示操作系统作业的开始与结束

指定要运行的程序名或命令

描述输入/输出设备(如磁带、打印机)

指定资源需求(如内存大小、CPU时间)

控制作业调度和作业的步骤顺序

结构特点:

JCL语句通常由一系列控制命令行组成

每一行描述一个操作或参数

通常是非交互式的文本命令

举例(简化形式):

在实际系统中(如IBM大型机), JCL会更加复杂, 例如:

作业说明书

💡

描述对一次计算机求解任务的控制方式

定义:

作业说明书是对整个作业的非形式化文档描述, 通常以书面或文档形式提供给操作员或系统, 说明作业的目的、步骤、输入输出要求等.

内容包括:

作业的功能说明(如“工资处理”、“库存更新”)

所需程序及其执行顺序

输入/输出文件名和格式

所需资源(如磁带数量、打印份数)

出错时的处理办法

特殊说明(如运行时间窗口)

举例:

两者关系与区别

项目	作业控制语言(JCL)	作业说明书
作用	提供机器可读的控制指令	提供人工可读的作业执行说明
面向对象	操作系统	操作员或系统管理员
表达方式	严格格式的语言语句	自然语言或文档形式
是否参与执行	是(直接控制作业调度和资源)	否(只是指导和辅助)
在哪里使用	随作业一起提交, 供操作系统解析	附加文档或说明, 供人工阅读参考

总结

作业控制语言(JCL)是批处理系统中用于控制作业运行的正式语言；

作业说明书是人工用于说明作业背景、目的、结构的辅助文档；

二者配合使用, 是早期大型机和批处理系统中作业管理的核心手段.

工作流程

用户提交作业(通常是通过打孔卡或磁带).

作业输入被收集成一批(batch), 由操作系统统一调度处理.

系统依次执行每个作业, 并将结果输出到指定设备(如打印机).

用户查看处理结果, 通常在作业完成一段时间之后.

主要特点

无交互性: 作业执行过程中用户无法干预.

自动化高: 系统自动完成作业的调度和执行.

吞吐量高: 适合大量作业集中处理, 提高资源利用率.

响应时间长: 作业从提交到结果输出需要较长时间.

作业调度机制简单: 一般使用先来先服务(FCFS)或最短作业优先(SJF)等简单策略.

典型结构图

应用场景

早期的大型机系统(如IBM 7090、UNIVAC等)

科学计算、工程分析

银行、财务、工资处理系统

现代系统中的定期批处理任务(如日志分析、报表生成)

与其他系统比较

特性	批处理操作系统	分时操作系统	实时操作系统
用户交互	无	有	有
响应时间	长(分钟到小时)	快(毫秒级)	非常快(确定时限)
作业处理方式	顺序自动执行	多用户并发	按优先级、时限
适用场景	批量处理、后台计算	多用户终端、开发环境	工控、嵌入式、航天

历史意义

批处理操作系统是操作系统发展的重要阶段, 奠定了作业调度、内存管理、I/O管理等现代操作系统的基础概念.

操作系统结构分类

下面是操作系统常见的几种体系结构: 单体式结构、层次式结构、虚拟机结构、微内核结构、客户/服务器结构 的简要介绍与对比:

单体式结构(Monolithic Architecture)

定义:

单体式操作系统将所有操作系统的功能(如进程管理、内存管理、文件系统、驱动程序等)全部集成在一个大模块中运行在内核态.

特点:

所有模块共享内核空间, 函数调用效率高

模块间耦合度高, 系统修改困难

易于实现, 但安全性和稳定性较差

代表系统:

Unix早期版本(如Version 6 Unix)

MS-DOS

层次式结构(Layered Architecture)

定义:

操作系统被划分为若干层, 每层只与相邻层交互. 下层为上层提供服务, 层与层之间有明确接口.

特点:

层次清晰, 便于调试和维护

信息隐藏良好, 高层无需关心底层细节

系统设计更复杂, 对层次划分要求高

典型结构示意:

代表系统:

THE系统(最早的层次式OS)

Multics(部分层次)

Linux中部分模块设计也具有层次性

虚拟机结构(Virtual Machine Architecture)

定义:

通过在硬件之上加入一个虚拟层(如VMM, 虚拟机监视器), 为每个用户创建一个完整的“虚拟计算机”环境, 多个虚拟机可以共享物理资源.

特点:

每个虚拟机看起来像一台真实计算机

安全性强, 各虚拟机之间相互隔离

资源利用率高, 可运行不同操作系统

代表系统:

IBM VM/370

现代的 VMware、VirtualBox、KVM

微内核结构(Microkernel Architecture)

定义:

将操作系统的基本功能(如进程管理、内存管理、IPC)保持在极小的内核中, 其他功能(文件系统、驱动等)移出内核, 作为用户态服务运行.

特点:

结构简洁, 内核小巧稳定

系统更容易扩展和移植

用户态与内核态频繁通信, 性能开销大

代表系统:

Mach(微内核理论的代表)

Minix 3

QNX(商用微内核)

客户/服务器结构(Client/Server Architecture)

定义:

操作系统按功能划分为服务器(提供资源和服务)与客户端(发起请求), 通常以进程或模块的形式存在, 采用消息传递通信.

特点:

松耦合、可扩展、灵活的模块设计

易于将部分服务分布在网络中

常与微内核或分布式系统结合使用

代表系统:

Windows NT系列部分服务采用C/S结构

分布式操作系统 Amoeba、Chorus

结构对比总结

结构类型	核心特点	优点	缺点	代表系统
单体式	所有模块集成在一个内核中	效率高, 设计简单	不易维护, 稳定性差	Unix早期、MS-DOS
层次式	模块分层, 按层次调用	易调试、清晰结构	分层不当可能引入性能问题	THE、Multics
虚拟机	模拟多个独立计算环境	隔离性强, 资源利用好	管理复杂, 性能略低	VM/370、VirtualBox
微内核	内核仅保留核心功能	可移植、安全性高	通信开销大	Mach、Minix、QNX
客户/服务器	服务模块化, 消息传递通信	模块解耦, 支持分布式	通信复杂、设计难度大	Windows NT、Amoeba

进程的三状态/七状态模型

进程的状态模型用于描述操作系统在调度和管理进程时, 进程可能处于的不同状态. 常见的模型有三状态模型和更精细的七状态模型.

三状态模型(最基础)

三种状态:

就绪(Ready)

进程已分配资源, 等待CPU执行.

运行(Running)

进程获得CPU, 正在执行.

阻塞(Blocked)/等待(Waiting)

进程在等待某个事件(如I/O完成), 无法运行或进入就绪队列.

状态转换图:

七状态模型(更精细)

为更准确描述进程在复杂调度系统中的行为, 七状态模型对三状态模型进行了扩展.

七种状态及说明:

新建(New)

进程正在创建, 还未加入就绪队列.

就绪(Ready)

进程已准备好执行, 等待CPU分配.

运行(Running)

进程正在CPU上执行.

阻塞(Blocked/Waiting)

等待某个事件完成(如I/O操作), 暂时无法继续执行.

就绪挂起(Ready Suspended)

就绪状态的进程被换出内存, 暂时保存在磁盘中.

阻塞挂起(Blocked Suspended)

阻塞状态的进程也被换出内存, 保存到磁盘中.

终止(Terminated)

进程执行完毕或被强制结束, 进入清理阶段.

状态转换简图:

两者的区别与联系

项目	三状态模型	七状态模型
状态数量	3	7
管理粒度	粗略(基本调度过程)	精细(包括挂起和创建/终止过程)
是否区分挂起状态	否	是(就绪挂起/阻塞挂起)
是否体现进程生命周期	部分(不含新建/终止)	全部(从新建到终止)
适用场景	教学/简单操作系统	多用户、虚拟内存等复杂系统

七状态模型存在的意义

支持虚拟内存与进程换出机制

明确进程的创建与终止过程

更好地管理系统资源与调度策略

Hoare’s Monitor 霍尔管程

下面我们用类封装(面向对象)的方式详细地说明 Hoare管程(Hoare Monitor) 的组成结构与行为.

Hoare管程的五大组成元素(类封装视角)

我们将 Hoare 管程视为一个封装共享资源的类(Monitor), 并借助条件变量类(Condition)来管理线程同步.

各部分解释(带类结构)

共享数据(Shared Data)

封装在 Monitor 类内部

所有线程通过 Monitor 的方法间接访问, 不能直接访问

入口过程(Entry Procedures)

操作共享数据的方法

所有方法都隐含互斥(即一次只能一个线程进入)

互斥机制(Mutual Exclusion)

保证同一时刻最多只有一个线程运行在 Monitor 内部

可类比隐含的 lock 机制, Java synchronized、Python threading.Lock

条件变量(Condition Variables)

每个条件变量表示一个特定的等待条件

注意: 在 Hoare语义中, signal() 会 立即将控制权交给被唤醒线程.

wait/signal 的 Hoare 语义行为

这与 Mesa 管程(如 Java 中的 notify())形成鲜明对比.

完整结构示意

(注: Python 中的 threading.Condition 实际遵循 Mesa 语义, 伪代码中仅用于代表 Hoare 行为)

Hoare管程执行顺序示意图

总结

组件	描述
Monitor类	封装共享资源、互斥锁和条件变量
共享数据	Monitor类中的字段
入口过程	对外暴露的同步方法
条件变量	表达等待/唤醒关系, 使用 wait() 和 signal() 控制执行顺序
Hoare语义特点	signal() 立即让出控制权, 被唤醒线程立即执行, 确保条件成立时被执行

可以这样理解:

Hoare管程就是一种将 👉锁(互斥机制) 👉条件变量(同步机制) 👉共享资源(关键数据) 集成封装在一个结构化对象中的并发控制机制.

更正式的理解方式:

管程(Monitor)是:

一种高级并发抽象结构, 将对共享资源的互斥访问与线程间的同步统一封装.

而 Hoare管程 是其中一种经典实现方式, 具有:

互斥访问: 内部操作隐含互斥(不需要用户显式加锁)

同步等待: 条件变量管理线程等待/唤醒

严格信号语义: signal() 会立即让出执行权给被唤醒线程(Hoare语义)

Hoare管程集成组件拆解:

组成元素	说明
锁	实现管程入口方法的互斥访问
条件变量(及其等待队列)	表达线程间的等待-唤醒关系
wait/signal	线程阻塞和唤醒的原语, 带有立即交接执行权的语义(Hoare语义)
共享数据	被封装的数据结构, 仅可通过 monitor 方法访问

其中next queue是锁mutex的等待队列

条件变量必须和锁绑定使用, 先持有锁再使用, 先释放锁再休眠

对比传统低层工具(信号量等)

特性	Hoare管程	手动使用信号量 / 条件变量
资源封装	✅ 结构清晰, 封装在对象中	❌ 程序员需显式管理
互斥管理	自动实现	需自行加锁/解锁
同步语义	条件变量 + 严格唤醒顺序(Hoare语义)	弱语义(如Mesa: notify不保证立即)
出错可能性	少, 结构化强	多, 极易出现死锁、竞争等问题

总结

💡

Hoare管程可以理解为把锁、信号量、条件变量等并发控制原语统一封装成一个安全的并发对象, 通过结构化的方式让程序员在使用时只关注逻辑条件而非底层控制细节, 并通过严格的唤醒语义保证线程在条件满足时立即执行.