说了这么多次 I/O,可你知道其中的原理么(三)

简介: 现在让我们转向对 I/O 软件的研究,I/O 软件设计一个很重要的目标就是设备独立性(device independence)。啥意思呢?这意味着我们能够编写访问任何设备的应用程序,而不用事先指定特定的设备。

缓冲

无论是对于块设备还是字符设备来说,缓冲都是一个非常重要的考量标准。下面是从 ADSL(调制解调器) 读取数据的过程,调制解调器是我们用来联网的设备。

用户程序调用 read 系统调用阻塞用户进程,等待字符的到来,这是对到来的字符进行处理的一种方式。每一个到来的字符都会造成中断。中断服务程序会给用户进程提供字符,并解除阻塞。将字符提供给用户程序后,进程会去读取其他字符并继续阻塞,这种模型如下

微信图片_20220414200248.png

这一种方案是没有缓冲区的存在,因为用户进程如果读不到数据会阻塞,直到读到数据为止,这种情况效率比较低,而且阻塞式的方式,会直接阻止用户进程做其他事情,这对用户来说是不能接受的。还有一种情况就是每次用户进程都会重启,对于每个字符的到来都会重启用户进程,这种效率会严重降低,所以无缓冲区的软件不是一个很好的设计。

作为一个改良点,我们可以尝试在用户空间中使用一个能读取 n 个字节缓冲区来读取 n 个字符。这样的话,中断服务程序会把字符放到缓冲区中直到缓冲区变满为止,然后再去唤醒用户进程。这种方案要比上面的方案改良很多。

微信图片_20220414200251.png

但是这种方案也存在问题,当字符到来时,如果缓冲区被调出内存会出现什么问题?解决方案是把缓冲区锁定在内存中,但是这种方案也会出现问题,如果少量的缓冲区被锁定还好,如果大量的缓冲区被锁定在内存中,那么可以换进换出的页面就会收缩,造成系统性能的下降。

一种解决方案是在内核中内部创建一块缓冲区,让中断服务程序将字符放在内核内部的缓冲区中。

微信图片_20220414200255.png

当内核中的缓冲区要满的时候,会将用户空间中的页面调入内存,然后将内核空间的缓冲区复制到用户空间的缓冲区中,这种方案也面临一个问题就是假如用户空间的页面被换入内存,此时内核空间的缓冲区已满,这时候仍有新的字符到来,这个时候会怎么办?因为缓冲区满了,没有空间来存储新的字符了。

一种非常简单的方式就是再设置一个缓冲区就行了,在第一个缓冲区填满后,在缓冲区清空前,使用第二个缓冲区,这种解决方式如下

微信图片_20220414200258.png

当第二个缓冲区也满了的时候,它也会把数据复制到用户空间中,然后第一个缓冲区用于接受新的字符。这种具有两个缓冲区的设计被称为 双缓冲(double buffering)

还有一种缓冲形式是 循环缓冲(circular buffer)。它由一个内存区域和两个指针组成。一个指针指向下一个空闲字,新的数据可以放在此处。另外一个指针指向缓冲区中尚未删除数据的第一个字。在许多情况下,硬件会在添加新的数据时,移动第一个指针;而操作系统会在删除和处理无用数据时会移动第二个指针。两个指针到达顶部时就回到底部重新开始。

缓冲区对输出来说也很重要。对输出的描述和输入相似

缓冲技术应用广泛,但它也有缺点。如果数据被缓冲次数太多,会影响性能。考虑例如如下这种情况,

微信图片_20220414200301.png

数据经过用户进程 -> 内核空间 -> 网络控制器,这里的网络控制器应该就相当于是 socket 缓冲区,然后发送到网络上,再到接收方的网络控制器 -> 接收方的内核缓冲 -> 接收方的用户缓冲,一条数据包被缓存了太多次,很容易降低性能。

错误处理

在 I/O 中,出错是一种再正常不过的情况了。当出错发生时,操作系统必须尽可能处理这些错误。有一些错误是只有特定的设备才能处理,有一些是由框架进行处理,这些错误和特定的设备无关。

I/O 错误的一类是程序员编程错误,比如还没有打开文件前就读流,或者不关闭流导致内存溢出等等。这类问题由程序员处理;另外一类是实际的 I/O 错误,例如向一个磁盘坏块写入数据,无论怎么写都写入不了。这类问题由驱动程序处理,驱动程序处理不了交给硬件处理,这个我们上面也说过。

设备驱动程序统一接口

我们在操作系统概述中说到,操作系统一个非常重要的功能就是屏蔽了硬件和软件的差异性,为硬件和软件提供了统一的标准,这个标准还体现在为设备驱动程序提供统一的接口,因为不同的硬件和厂商编写的设备驱动程序不同,所以如果为每个驱动程序都单独提供接口的话,这样没法搞,所以必须统一。

分配和释放

一些设备例如打印机,它只能由一个进程来使用,这就需要操作系统根据实际情况判断是否能够对设备的请求进行检查,判断是否能够接受其他请求,一种比较简单直接的方式是在特殊文件上执行 open操作。如果设备不可用,那么直接 open 会导致失败。还有一种方式是不直接导致失败,而是让其阻塞,等到另外一个进程释放资源后,在进行 open 打开操作。这种方式就把选择权交给了用户,由用户判断是否应该等待。

注意:阻塞的实现有多种方式,有阻塞队列等

设备无关的块

不同的磁盘会具有不同的扇区大小,但是软件不会关心扇区大小,只管存储就是了。一些字符设备可以一次一个字节的交付数据,而其他的设备则以较大的单位交付数据,这些差异也可以隐藏起来。

用户空间的 I/O 软件

虽然大部分 I/O 软件都在内核结构中,但是还有一些在用户空间实现的 I/O 软件,凡事没有绝对。一些 I/O 软件和库过程在用户空间存在,然后以提供系统调用的方式实现。


相关文章
|
3月前
|
缓存 安全 API
【深度解析】嵌入式第三方集成的优势、挑战与实现方案(2025版)
嵌入式第三方集成是将外部服务无缝嵌入自身系统的技术方案,通过API/SDK实现功能内嵌(如支付、会议),提升用户体验和开发效率。其核心优势包括操作流畅性、降低研发成本及快速迭代能力,但需解决接口稳定性、数据同步等挑战。实施时需注重架构设计(微服务、安全策略)和性能优化(缓存、异步处理)。未来趋势将向AI服务集成、无代码平台发展,同时安全合规要求更严格。建议选择可靠服务商、遵循最佳实践,并持续监控优化集成方案。
179 2
|
3月前
|
数据可视化 搜索推荐 语音技术
还在花钱转语音?10,000+ star 开源「ebook2audiobook」白嫖1107种语言!免费文字秒变多语言音频!
开源工具「ebook2audiobook」支持1107+语言,可将电子书一键转为有声书,适配EPUB、PDF等多种格式,功能强大且免费,助力听书、学习与内容创作。
279 0
|
7月前
|
消息中间件 人工智能 自然语言处理
基于 RocketMQ 事件驱动架构的 AI 应用实践
基于 RocketMQ 事件驱动架构的 AI 应用实践
210 2
|
9月前
|
运维 监控 安全
《筑牢安全防线:鸿蒙Next ArkTS中的模型安全审计与漏洞检测》
在鸿蒙Next ArkTS开发中,模型的安全审计和漏洞检测至关重要。本文探讨如何利用HiChecker进行基础检测、审计日志管理与分析、静态代码分析、模型加密与签名及实时监控与异常检测等手段,确保模型的安全可靠运行,保护用户数据安全,提升应用稳定性。
302 32
|
9月前
|
人工智能 自然语言处理 搜索推荐
《解锁鸿蒙Next系统人工智能语音助手开发的关键步骤》
在鸿蒙Next系统上开发人工智能语音助手应用,需经历环境搭建、权限申请、集成语音识别、自然语言处理、语音合成及智能交互逻辑设计等关键步骤。开发者使用DevEcoStudio工具,引入Core Speech Kit和NLP服务,实现从语音输入到文本理解再到语音输出的全流程开发。通过多轮对话、个性化功能和全面测试优化,打造稳定可靠的语音助手应用,提供智能便捷的用户体验。
469 22
|
12月前
|
Swift UED
理解 Swift 事件传递和响应过程
【10月更文挑战第20天】事件传递和响应是 Swift 开发中不可或缺的部分,掌握其过程和机制对于构建高质量的应用至关重要。通过深入了解事件的产生、传递、响应者链的形成、响应者的选择和响应等环节,你能够更好地设计和实现交互功能,提升用户体验。同时,注意优化和避免常见问题,确保应用的性能和稳定性。
243 58
|
11月前
|
运维 Prometheus 监控
运维自动化:提高IT效率的关键策略
在当今快速发展的IT领域,运维自动化已成为企业提升运营效率、降低错误率和成本的重要手段。随着云计算、大数据和人工智能技术的不断进步,实现运维流程的自动化不仅可行,而且变得日益重要。本文探讨了运维自动化的概念、关键技术及其在实际工作中的应用,旨在为IT专业人士提供一种高效管理和维护系统的方法。
|
11月前
|
存储 安全 搜索推荐
理解Session和Cookie:Java Web开发中的用户状态管理
理解Session和Cookie:Java Web开发中的用户状态管理
229 4
|
11月前
|
消息中间件 存储
消息队列的挑战与解决方案:丢失、重复与积压问题
消息队列(MQ)在分布式系统中扮演着重要的角色,用于解耦服务、异步处理任务和提高系统吞吐量。然而,在使用消息队列时,我们可能会遇到消息丢失、重复和积压等问题。本文将探讨这些问题的成因以及相应的解决方案。
359 1
|
12月前
|
搜索推荐 前端开发 数据安全/隐私保护
改善用户体验方法
【10月更文挑战第9天】改善用户体验方法
876 3