许式伟的架构课
许式伟
七牛云 CEO
84945 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 89 讲
许式伟的架构课
15
15
1.0x
00:00/00:00
登录|注册

13 | 进程间的同步互斥、资源共享与通讯

通过 URL Scheme 调用其他进程
不支持创建子进程
支持事件(Event)同步原语
使用名称标识互斥资源
使用共享内存标识互斥资源
Windows 的命名管道(NamedPipe)
UNIX 域
基于网络的套接字通讯
共享内存
剪贴板
文件系统
条件变量(Cond)
等待组(WaitGroup)
信号量(Semaphore)
读写锁(RWMutex)
锁(Mutex)
iOS 的改变是对的,使进程、线程和协程分工更为清晰
进程间协同的需求演进剧烈变动
iOS 的改变是基于安全考虑
进程间协同只需要有另一个进程能力的调用
进程应该是子系统级别的边界
剪贴板作为一种用户实现跨进程交互的手段
文件系统被沙箱隔离
进程间通讯通过 URL Scheme 实现
软件不再创建多个进程实例,永远是单例的
iOS
Windows
Linux
Shell 配合执行某个动作
创建子进程
收发消息
资源共享
同步
互斥
结语
架构思维
iOS 的改变
操作系统差异
进程间启动
进程间协同机制
进程间的同步互斥、资源共享与通讯

该思维导图由 AI 生成,仅供参考

你好,我是七牛云许式伟。
在上一讲,我们介绍了进程内执行体之间的协同机制。今天我们接着聊进程与进程之间的协同。
这些协同机制大体可分为:互斥、同步、资源共享以及通讯等原语。对于这些协同机制,我们对比了 Linux、Windows、iOS 这三大操作系统的支持情况,整理内容如下:
在逐一详细分析它们之前,我们先讨论一个问题:从需求角度来讲,进程内协同与进程间协同有何不同?
在早期,操作系统还只有进程这个唯一的执行体。而今天,进程内的执行体(线程与协程)被发明出来并蓬勃发展,事情发生了怎样的变化?
请先思考一下这个问题。我们在这一讲最后总结的时候一起聊聊。

启动进程

在讨论进程间的协同前,我们先看下怎么在一个进程中启动另一个进程。这通常有两种方法:
创建子进程;
让 Shell 配合执行某个动作。
前面在 “11 | 多任务:进程、线程与协程” 一讲中我们已经提到过,创建子进程 UNIX 系的操作系统都用了 fork API,它使用上很简洁,但是从架构角度来说是一个糟糕的设计。Windows 中我们用 CreateProcess,这个函数有很多的参数。
iOS 很有意思,它并不支持创建子进程。在进程启动这件事情上,它做了两个很重要的变化:
软件不再创建多个进程实例,永远是单例的;
一个进程要调用另一个进程的能力,不是去创建它,而是基于 URL Scheme 去打开它。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文从需求角度出发,探讨了进程内协同与进程间协同的不同之处,并介绍了进程间协同的主要方式和操作系统的支持情况。文章首先讨论了进程的启动方法,包括创建子进程和Shell配合执行动作。接着详细介绍了同步与互斥体,包括锁、读写锁、信号量等原语,并对比了不同操作系统的支持情况。在资源共享方面,文章重点介绍了文件系统和共享内存的进程间通讯机制,以及iOS操作系统中对文件系统的独立隔离。总体而言,本文深入浅出地介绍了进程间协同的重要概念和技术特点,为读者提供了系统的了解和认识。 文章还探讨了进程间通讯的其他方式,如基于网络的套接字通讯和UNIX域,以及Windows平台的命名管道。此外,通过对比不同操作系统的进程间协同机制,文章强调了iOS操作系统对进程间协同的大刀阔斧的改变,强调了其对进程边界的清晰分工和对多余协同机制的削减。这种创新性的系统设计带来了对进程通讯机制必要性的思考,以及对架构设计中需求分析和概要设计的重要性的强调。 总的来说,本文通过深入的技术讨论,引发了对进程间协同机制的思考和讨论,为读者提供了对操作系统中进程间通讯的全面认识和启示。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《许式伟的架构课》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(38)

  • 最新
  • 精选
  • tim
    信号量(system V) 有一个属性是un-do,如果进程挂掉,这个进程获得的资源会释放。避免死锁饿死的问题

    作者回复: 👍,很好的补充

    2019-06-05
    2
    29
  • ヾ(◍°∇°◍)ノ゙
    非常同意作者观点啊!另外有个疑惑就是Chrome浏览器是多进程设计的,据说是为了追求性能,许总怎么看?

    作者回复: 从客户端软件角度,多进程、多线程甚至多协程的性能差异很小。所以思考不应该是从性能出发,我觉得应该从隔离性出发,多进程的好处是隔离性好,一个出问题不影响别人。

    2019-06-19
    3
    24
  • ljf10000
    ios有点docker的意思

    作者回复: 是的,不过它出现得比docker早好多年。

    2019-05-28
    17
  • BillyZhang
    有一点不太理解,IOS 是手机或是移动操作系统,linux和windows 是pc 或是服务器操作系统,虽然安卓也是基于linux 但是 使用场景还是不太一样的吧, 那么同是苹果操作系统 MacOS 是否也是沙箱设计模式呢?

    作者回复: macos 不是沙箱设计

    2019-05-31
    6
  • L-jiehui
    老师思维高度很高,再一次收获巨大,谢谢老师 有两个问题请教下老师: 1、操作系统如果不知道信号量的值多少才合理,不能统一按照自定义默认的值,例如0来处理吗 2、虚拟内存实现进程隔离具体如何实现的呢,网上看了一遍资料,还是理解得不够清晰

    作者回复: 1、0未必与事实相符,不相符会导致逻辑错乱 2、见我们前面 “07 | 软件运行机制及内存管理” 一节

    2019-05-28
    6
  • Cordova
    我觉得iOS这样设计挺好的,本来就该思考这个系统面对的是什么样的使用场景,也许我们以后只需要一个用户进程呢、只不过这个用户进程功能很强大、当系统变得微小化、各种设备被变得多样化、不需要去协调用户进程、需要什么数据问问另外一个微系统设备就好啦、那这样我们的以后的系统就只需要为这一个进程保留一个套接字就好啦!所以iOS我觉得代表了以后的方向和趋势!反正听完许老师的课我是想法很多~不过可能明天早上爬起来又背着电脑,坐着公交去上班了。

    作者回复: 挺有想法的,不过所有的预见都应该建立在逻辑上,需求是怎样演进的,所以技术会怎么变,这才是架构师预见未来的判断法则。

    2019-05-29
    5
  • 82
    1,ios进程单实例就没法做到android的应用双开能力吧? 2,在使用url scheme进程通讯时,如果存在多进程实例,是否会让系统疑惑跳转到哪个进程? 3,一台机器就是一个局域网,每个进程实例都是一个端,这种通讯思想似乎拓宽了网络的边界,无处不网络。

    作者回复: 1、是的,架构设计是选择,你没法兼顾 2、这个是个理由;简单也可以是理由

    2019-05-28
    5
  • 麋鹿在泛舟
    "为什么?因为进程可能会异常挂掉,这会导致同步和互斥的状态发生..." 请教个问题,线程难道不会因为挂死而异常么? 如果这时候持有锁,其他线程同样的会持续拿不到锁而阻塞了。

    作者回复: 线程没法独立挂掉,进程会一起挂。

    2019-05-31
    3
    4
  • Geek_04e22a
    老师,读了这篇文章,感觉收货颇丰,以前所有机制只认为是进程间通讯,没有想过重新划分同步互斥,资源共享,收发消息几类。现在有两个问题,iOS共享资源使用的是剪切板吗?Linux创建子进程目的是什么?

    作者回复: 1、剪贴板是这里拿来凑数的,它并不是惯常的进程间通信手段; 2、Unix 系的操作系统认为所有进程都有一个祖先,进程关系构成一个进程树。

    2019-05-28
    2
    4
  • zhuyc
    "规格强调的是自然体现需求,所以规格是稳定的,是子系统的契约。"关注规格与契约的讨论,后面有没有机会更详细展开看看。 我能理解接口与实现的分离,老师提到的规格似乎是更高层的概念

    作者回复: 规格就是指接口

    2019-07-06
    2
收起评论
显示
设置
留言
38
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部