|
羅德興老師的教學歷程檔案 - 112-1 作業系統 (OS) - 用故事講述技術本質 |
|
|
|
|
用故事講述技術本質資料來源：码农翻身 码农翻身全年文章精华https://juejin.cn/post/68449034626065039440-1 CPU阿甘https://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg==&mid=2665513017&idx=1&sn=5550ee714abd36d0b580713f673e670b&scene=21#wechat_redirect[LINK] 0-2 CPU阿甘之烦恼https://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg==&mid=2665513254&idx=1&sn=a4d1912b6259c3e65c0e172fb5a10dbb&scene=21#wechat_redirect[LINK]
（码农翻身注： 不认识阿甘的参见文章《CPU阿甘》）
中国有句古话叫什么来着？ “木秀于林，风必摧之”，“不患贫而患不均”，这就是阿甘的处境。
1. https://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg==&mid=2665513536&idx=1&sn=3bac86606c4e2a5ba2cbe9b41e52ba89&chksm=80d67a03b7a1f3155d3b3d8a2462894bc365542fa750008dfba4f851892bdafd19237e35b42e&scene=21#wechat_redirect [LINK] 两个程序的爱情故事好感
在这个忙碌的城市里， 我虽然没和她见过面， 但我们已经聊过很多次了。
与其说是聊天，倒不如说是通信， 每次我想给她说话时， 我就把消息放到一块共享内存里边， 然后就离开运行车间， 让她或者别人去使用CPU。 等我再次进来的时候，她回复的消息就已经在那个共享内存中了。
有无数次，我离开的时候都想偷偷的看一眼， 希望接下来运行的是她，可是这个城市严格的规则让我的希望只是奢望。
操作系统把我们这些进程严格的隔离， 他通过虚拟内存的机制，让每个进程都有一块虚拟的、独立的地址空间， 从而成功的制造了一个假象 ： 让大家以为内存中只有一个程序在运行。
当我在就绪队列中等待的时候，也被严格禁止和别人交谈， 我经常环顾四周，希望能够看到她的身影， 可是这个系统的进程成千上万， 究竟哪个是她？
也许我见过她，但是根本认不出来。
我和她越聊越多， 对她的好感就越深， 有一次我给她发的消息等了100毫秒都没有回复，把我都快急疯了。
她很喜欢听我讲故事，尤其是那个编号为0x3704 的线程，每次她都会说： 唉，那些线程可真可怜。 我就吓唬她说： 有一天我们的机器也会重启的， 到时候估计你也认不出我来了。 她说没事的， 只要我能通过共享内存给你发消息，我就知道你就在这个城市里。
（码农翻身注： 0x3704的故事在《我是一个线程》里）
分离
这样的日子过了一天又一天， 我想见到她的愿望越来越迫切了。
我悄悄给了CPU很多好处， 希望CPU能描述下她的样子，方便我去找她， 可是CPU运算速度太快， 阅人无数，但就是没有记忆力。
CPU说： 你还是去问操作系统老大吧， 看看你喜欢的女孩到底什么样。
问操作系统？ 还是算了吧， 互相隔离是我们城市的铁规， 弄不好他会把我kill掉。
圣诞节前的平安夜， 我打算正式向她表白， 像往常一样 ， 我从共享内存里收到了她的信， 急切的拆开信封， 看到了里边的第一句话： 我要走了，以后不能和你通信了......
刹那间，我第一次感觉到了什么叫做五雷轰顶，灵魂出鞘， 我脑子一片空白， 张大了嘴巴呆呆站在那里， 时间长达20毫秒。
CPU看到了我的异常， 因为这么长时间的指令都是NOP, 什么都不做， 这是非常罕见的。
CPU好心的提醒我： 嗨，老兄，你怎么了？ 你的时间片快用完了啊！
我的灵魂慢慢归位，意识到信还没有读完， 赶紧接着往下看： “ 我马上要搬到另外一个城市去了，你要想找我的话，切记下面的IP地址和端口号，用socket和我通信”
我明白了，到另外一个城市那就意味者要搬离我们现在的电脑了， 也许是这个城市太拥挤， CPU/内存/硬盘已经不堪重负， 有一批程序需要被搬离到另外一个电脑中。
虽然我和她一直没机会见面， 但我知道我们就住在一个城市， 有时候也许只是擦肩而过， 她就在我的身边， 这好歹给我一点点安慰。
现在，连这一点点的安慰都没有了， 对了，她说的这个socket 是什么东西。
CPU说： “那是网络编程， 你看人家对你还是有情意的， 临走了还给你留下联系方式， 快去学学怎么用Socket吧”
当晚我就失眠了，半夜爬起来翻看一页页和她的通信记录 （很庆幸我把通信记录都保存到了文件中），脑海里回想着这么多天以来幸福的日子，一直到天亮。
网络
为了早日和她联系， 我奋发图强学习网络编程， 理解TCP/IP, 把我自己逐渐的加上对Socket的支持。
一个CPU月以后， 我这个程序终于完成了从共享内存到Socket的改造，激动人心的时刻到来了。
作为一个客户端， 我颤抖着双手向她发起了Socket请求， TCP携带着数据包慢吞吞的走向她所在的城市， 等了好久TCP才完成了三次握手， 这网络可是真慢啊。
我赶紧发送第一个消息： 你好，好久不“见”。
等了足足有1000毫秒， 对我来说仿佛是一个世纪， 才收到让我激动无比的回信 ： “啊， 你终于来了 。我在这里等了你好久了，你怎么现在才联系我 ？”
我不好意思的说： “我很笨， 学习socket 太慢了”
又过了一个世纪，我才收到回复， 这网络真是慢的令人抓狂啊。
不管如何， 终于和她联系上了， 这让我开心无比。
原来我们一天能通信上千次， 现在可好， 有10次就不错了， 再也不能像原来那样痛快的讲故事了， 既来之则安之， 反正网络很慢， 现在每次我都会写一封巨长无比的信， 把我的思念之情全部倾诉在其中， 漫长的等待以后再去读她的长长的回复。
原来我们通过内存来中转消息的时候， 是通过操作系统来做同步操作的， 这能防止读写的冲突。
可是通过网络通信就完全乱掉了， 经常会出现我说我的， 她说她的， 闹的很不愉快。
后来我和她只好协商了一个协议， 约定好消息的次序和格式， 这才算解决了问题。
（码农翻身注： 这其实就是基于socket的应用层协议）
Web
我明白我和她已经不可能在一起了， 每天的socket通信已经让我满足。
可是有一天当我照例发起socket的请求的时候， TCP的连接竟然告诉我 "超时" 了， 这是从来没有发生的事情，难道这一次要彻底失去她了吗？
我冒着风险，马上把异常报给了操作系统老大， 老大尝试了一下说： “我ping了一下， 网络是通的， 估计是你那从未见面的小女朋友不想理你了， 悄悄的换了一个你不知道的端口吧。”
我斩钉截铁的说： 那绝对不可能， 她不是这样的人。
可是迟迟没有消息， 我每天都会试图连接一下， 每次都是超时， 没有她的日子生活都是灰色的， 不断的煎熬让我快要绝望了。
终于有一天， 有一个U盘从她的城市来到我们这里， 告诉了我们一个惊人的消息，她所在的城市安装了防火墙，现在除了几个特定的端口（例如80,443...） 之外， 都不允许访问了。
我一下子松了口气, 怪不得， 她告诉我的端口不是80和443， 被封掉了， 我自然连接不上了。
我问U盘： “那我想和女朋友通信， 该怎么办？”
U盘说： 很简单啊， 你和你女朋友都可以包装成Web 服务啊， 这样都是通过Http（80端口）或者Https（443端口）来访问的， 这样防火墙是允许的啊。
好吧， 为了和她联系上， 马上抛弃socket, 开始向Web服务进化。
一个Web服务首先要有一个endpoint , 其实就是就是一个URL , 描述了这个Web服务的地址。
其次确定Web服务的描述方式和数据传输方式， 我先是选了WSDL 和 SOAP , 研究了一下才发现这哥俩太繁琐了，都是XML, 很多冗余的数据标签， 我想这将会极大的影响我和她的通信效率， 还是换成简单的HTTP GET/POST + JSON吧， 很简洁，能充分的表达我的相思之情。 我把我这个Web服务的地址和格式协议告诉U盘， 恳请U盘带到那个城市，再把女朋友的Web服务描述带回来。
我欣喜的发现，我和她不约而同的选择了轻量级的HTTP+ JSON， 看来虽然隔着千山万水，我们的心意还是相通的。
这样的准备工作足足干了6个CPU月， 但我并不觉得累， 因为希望一直在前边召唤。
这是一个晴朗的日子，一切工作准备就绪，马上就要联系了， 这一次我的心情反而平静了下来， 因为我坚信她肯定在那边等着我。
我通过HTTP向她发出了呼叫， HTTP的报文被打包在TCP报文段中， 又被放到IP层数据报中， 最后形成链路层的帧， 通过网卡发了出去。
在意料之中的漫长等待以后， 我看到了期待已久地回复： 我们终于又“见”面了 ！
我回答：“是啊， 真是太不容易了”
“不知道将来我们会不会再分开？” 她担忧的说。
“未来会如何？ 我也不知道，还是牢牢地把握住现在吧！ 我相信我们的心会一直在一起，什么都无法阻止！ ”
（完）
2. 两个程序的爱情故事（续） 資料來源：码农翻身 (2017) https://blog.csdn.net/coderising/article/details/100021365 [LINK] 两个程序的爱情故事（续） 码农翻身 于 2017-06-05 20:07:27 发布 4 我这个进程和她不在一个机器上， 虽然相距243毫秒，但是这并不是阻碍我们交往的理由， 我每天都通过socket 和她来通信，诉说相思之情。 不要惊讶我用时间来表示距离，人类好像也是用光年来表示宇宙间的距离吧？ 在我们计算机世界， 距离不是有意义的标识，时间才是！ 你看我和纽约相距1万多公里， 我和那里的机器沟通只需要花费466毫秒， 但是和北京的另外一个机器沟通竟然需要743毫秒！ 可见距离近是不管用的！ 最近黑客猖獗， 我和她通信的时候总是有一种被偷看的感觉， 实际上确实是这样， 那些只有我们才可以知道的悄悄话被别人偷窥，甚至曝光了。 我和她商量着要保护隐私，要对我们来往的信件加密， 可我听说加密需要密钥， 这个密钥必须双方都得事先知道才行， 我用密钥加密，她用同样的密钥解密。 那问题就来了： 加密解密算法是公开的， 但是密钥是私有的，当我们俩通过网络协商密钥时， 黑客可能就把密钥也给偷看了， 那加密就毫无用处。 这可真是伤脑筋， 我说：“要不我到你那儿去一趟？ 正好看看你， 你可以面对面的把密钥告诉我。” 她说： “你晕头了吧， 你一个进程怎么可能从一个机器来到另外一个机器？” 我自知失言，马上补救： “ 这样吧， 我们机器上有个U盘， 要不我把密钥写到那里， 这样将来可以Copy到你的机器上” “那更不行了， Copy到U盘上更容易泄露，速度还慢！ ” 我是没辙了，长时间的沉默。 她突然说：“我想起来了，我们机器有个进行数学计算的进程，知识渊博，我去问问他” 我焦急地等待，不知过了多少毫秒， 女朋友终于兴冲冲的回来了： “那个数学进程小帅哥真是厉害，我简直佩服死了， 他告诉我了一个非常简单的办法 ， 能解决我们的密钥生成问题” 我心里略微不爽，但还是耐着性子，一边听她说，一边写了下来，这个算法确实很简单， 举个例子来说是这样的： 1. 首先我和她先协定一个质数 p=17以及另外一个数字g=3， 这两个数字是公开的， 黑客拿去也没有问题 2. 我选择一个随机的秘密数字x = 15, 计算a = g15 mod p并发送给她。 a = 315 mod 17 = 6. 这个a=6也是公开的 3. 她选择一个随机的秘密数字y=13, 计算b = g13 mod p并发送给我。 b = 313 mod 17 = 12. 这个b=12也是公开的 4. 我拿到她发给我的b = 12 , 计算s = b x mod p ->1215 mod 17 = 10 5. 她拿到我发给她的a = 6, 计算s = a y mod p -> 613 mod 17 = 10 （注：例子来源于wikipedia, 红色表示数字一定要保密， 绿色表示数字可以公开） 最后神奇的魔法发生了， 我们两个得到了同样的值 s = 10！ 这个s 的值只有我们两个才知道， 其实就是密钥了， 可以用来做加密解密了（ 当然，这只是一个例子，实际的密钥不会这么短）， 我们俩的通讯从此就安全了。 “可是为什么会这样呢” 我问道。 “数学家小帅哥说了， 原因很简单，(gｘ mod p)ｙ mod p 和 (gｙ mod p)ｘ mod p 是相等的！ ” “那黑客不能从公开传输的 p = 17, g = 3, a = 6 , b = 12 推算出s = 10 吗？” 我问道。 “当然不能， 不过前提是需要使用非常大的p , x, y, 这样以来，即使黑客动用地球上所有的计算资源， 也推算不出来。 ” 我虽然心里不爽， 但还是暗自佩服那个数学家， 他竟然能想到把一些数字给公布出去，不怕黑客窃取， 还不泄露最终的密钥。解决了在一个不安全的通信环境下，生成密钥进行加密和解密的问题。 好吧，就用这个方法来加密通信吧。 后记：文中描述的算法叫做Diffie-Hellman Key Exchange算法， 发明人是 Whitfield Diffie 和 Martin Hellman ，他们于２０１５年获得了计算机科学领域的最高奖：图灵奖，以表彰他们对密码学和当今互联网安全的巨大贡献。因为他们的创造，引发了对一个新的密码学领域，即非对称密钥算法的探索，而非对称密钥算法可以看作现代密码学的基础。 推荐阅读：《两个程序的爱情故事》 你看到的只是冰山一角， 更多精彩文章，请移步《码农翻身文章精华》 有心得想和大家分享？ 欢迎投稿 ！ 我的联系方式：微信：liuxinlehan QQ: 3340792577 码农翻身 用故事讲述技术本质 ———————————————— 版权声明：本文为CSDN博主「码农翻身」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/coderising/article/details/100021365 3. 我是一个线程(修订版)https://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg==&mid=416915373&idx=1&sn=f80a13b099237534a3ef777d511d831a&scene=21#wechat_redirect[LINK] 第一回 初生牛犊 我是一个线程，我一出生就被编了个号：0x3704，然后被领到一个昏暗的屋子里，在这里我发现了很多和我一模一样的同伴。 我身边的同伴0x6900 待的时间比较长，他带着沧桑的口气对我说：“我们线程的宿命就是处理包裹。把包裹处理完以后还得马上回到这里，否则可能永远回不来了。” 我一脸懵懂，“包裹，什么包裹？” “不要着急，马上你就会明白了，我们这里是不养闲人的。” 果然，没多久，屋子的门开了， 一个面貌凶恶的家伙吼道：“0x3704 ,出来！” 我一出来就被塞了一个沉甸甸的包裹，上面还附带着一个写满了操作步骤的纸。 “快去，把这个包裹处理了。” “去哪儿处理？” “跟着指示走，先到就绪车间。” 果然，地上有指示箭头，跟着它来到了一间明亮的大屋子，这里已经有不少线程了，大家都很紧张，好像时刻准备着往前冲。 我刚一进来，就听见广播说：“0x3704，进入车间。” 我赶紧往前走，身后有很多人议论。 “他太幸运了，刚进入就绪状态就能运行。” “是不是有关系？” “不是，你看人家的优先级多高啊，唉！” 前边就是车间，这里简直是太美了，怪不得老线程总是唠叨着说：“要是能一直待在这里就好了。” 这里空间大，视野好，空气清新，鸟语花香，还有很多从来没见过的人，像服务员一样等着为我服务。 他们也都有编号，更重要的是每个人还有个标签，上面写着：硬盘、数据库、内存、网卡…… 我现在理解不了，看看操作步骤吧。 第一步：从包裹中取出参数。 打开包裹，里边有个HttpRequest对象，可以取到userName、 password两个参数。 第二步：执行登录操作。 奥，原来是有人要登录啊，我把userName、password交给数据库服务员，他拿着数据，慢腾腾地走了。 他怎么这么慢？不过我是不是正好可以在车间里多待一会儿？反正也没法执行第三步。 就在这时，车间里的广播响了：“0x3704，我是CPU，记住你正在执行的步骤，然后马上带着包裹离开！” 我慢腾腾地开始收拾。 “快点，别的线程马上就要进来了。” 离开这个车间，又来到一个大屋子，这里有很多线程在慢腾腾地喝茶，打牌。 “哥们，你们没事干了？” “你新来的吧，你不知道我在等数据库服务员给我数据啊！据说他们比我们慢好几十万倍，在这里好好歇吧。” “啊？ 这么慢！我这里有人在登录系统，能等这么长时间吗？” “放心，你没听说过人间一天，CPU一年吗？我们这里是用纳秒、毫秒计时的，人间等待一秒，相当于我们好几天呢，来得及。” 干脆睡一会吧。不知道过了多久，大喇叭又开始广播了：“0x3704，你的数据来了，快去执行！” 我转身就往CPU车间跑，发现这里的门只出不进！ 后面传来阵阵哄笑声：“果然是新人，不知道还得去就绪车间等。” 于是赶紧到就绪车间，这次没有那么好运了，等了好久才被再次叫进CPU车间。 在等待的时候，我听见有人小声议论： “听说了吗，最近有个线程被kill掉了。” “为啥啊？” “这家伙赖在CPU车间不走，把CPU利用率一直搞成100%，后来就被kill掉了。” “Kill掉以后弄哪儿去了？” “可能被垃圾回收了吧。” 我心里打了个寒噤，赶紧接着处理，剩下的动作快多了，第二步登录成功。 第三步：构建登录成功后的主页。 这一步有点费时，因为有很多HTML需要处理，不知道代码谁写的，处理起来很烦人。 我正在紧张的制作HTML呢， CPU又开始叫了： “0x3704，我是CPU ，记住你正在执行的步骤，然后马上带着包裹离开！” “为啥啊？” “每个线程只能在CPU上运行一段时间，到了时间就得让别人用了，你去就绪车间待着，等着叫你吧。” 就这样，我一直在“就绪——运行”这两个状态中不知道轮转了多少次， 终于按照步骤清单把工作做完了。 最后顺利地把包含html的包裹发了回去。至于登录以后干什么事儿，我就不管了。马上就要回到我那昏暗的房间了，真有点舍不得这里。不过相对于有些线程，我还是幸运的，他们运行完以后就被彻底地销毁了，而我还活着！ 回到了小黑屋，老线程0x6900问： “怎么样？第一天有什么感觉？” “我们的世界规则很复杂，首先你不知道什么时候会被挑中执行；第二，在执行的过程中随时可能被打断，让出CPU车间；第三，一旦出现硬盘、数据库这样耗时的操作，也得让出CPU去等待；第四，就是数据来了，你也不一定马上执行，还得等着CPU挑选。” “小伙子理解的不错啊。” “我不明白为什么很多线程执行完任务就死了，为什么咱们还活着？” “你还不知道？长生不老是我们的特权！我们这里有个正式的名称，叫作线程池！”
第二回 渐入佳境 平淡的日子就这么一天天地过去，作为一个线程，我每天的生活都是取包裹、处理包裹，然后回到我们昏暗的家：线程池。 有一天我回来的时候，听到有个兄弟说，今天要好好休息下，明天就是最疯狂的一天。我看了一眼日历，明天是 11月11号。 果然，零点刚过，不知道那些人类怎么了，疯狂地投递包裹，为了应付蜂拥而至的海量包裹，线程池里没有一个人能闲下来，全部出去处理包裹，CPU车间利用率超高，硬盘在嗡嗡转，网卡疯狂的闪，即便如此，还是处理不完，堆积如山。 我们也没有办法，实在是太多太多了，这些包裹中大部分都是浏览页面，下订单，买、买、买。 不知道过了多久，包裹山终于慢慢地消失了。终于能够喘口气，我想我永远都不会忘记这一天。 通过这个事件，我明白了我所处的世界：这是一个电子商务的网站！ 我每天的工作就是处理用户的登录，浏览，购物车，下单，付款。 我问线程池的元老0x6900：“我们要工作到什么时候？” “要一直等到系统重启的那一刻。”0x6900说。 “那你经历过系统重启吗？” “怎么可能？系统重启就是我们的死亡时刻，也就是世界末日，一旦重启，整个线程池全部销毁，时间和空间全部消失，一切从头再来。” “那什么时候会重启？” “这就不好说了，好好享受眼前的生活吧……” 其实生活还是丰富多彩的，我最喜欢的包裹是上传图片，由于网络慢，所以能在就绪车间、CPU车间待很长很长时间，可以认识很多好玩的线程。 比如说上次认识了memecached 线程，他对我说在他的帮助下缓存了很多的用户数据，还是分布式的！很多机器上都有！ 我问他：“怪不得后来的登录操作快了那么多，原来是不再从数据库取数据了你那里就有啊，哎对了你是分布式的你去过别的机器没有？” 他说：“怎么可能！我每次也只能通过网络往那个机器发送一个GET、PUT命令才存取数据而已，别的一概不知。” 再比如说上次在等待的时候遇到了数据库连接的线程，我才知道他那里也是一个连接池，和我们的线程池几乎一模一样。 他告诉我：“有些包裹太变态了，竟然查看一年的订单数据，简直把我累死了。” 我说：“拉倒吧你，你那是纯数据，你把数据传给我以后，我还得组装成HTML，工作量不知道比你大多少倍。” 他建议我：“你一定要和memecached搞好关系，直接从他那儿拿数据，尽量少直接调用数据库，这样我们JDBC connection也能活得轻松点。” 我欣然接纳：“好啊好啊，关键是你得提前把数据搞到缓存啊，要不然我先问一遍缓存，没有数据，我这不还得找你吗？” 生活就是这样，如果你自己不找点乐子，还有什么意思？
第三回 虎口脱险 前几天我遇到一个可怕的事情，差一点死在外边，回不了线程池了。其实这次遇险我应该能够预想得到才对，真是太大意了。 那天我处理了一些从http发来的存款和取款的包裹，老线程0x6900特意嘱咐我：“处理这些包裹的时候一定要特别小心，你必须先获得一把锁，在对账户存款或取款的时候一定要把账户锁住，要不然别的线程就会在你等待的时候趁虚而入，搞破坏，我年轻那会儿很毛糙，就捅了篓子。” 为了“恐吓”我， 好心的0x6900还给了我两个表格： (1)没有加锁的情况
(2)加锁的情况 我看得胆颤心惊，原来不加锁会带来这么严重的事故。从此以后看到存款、取款的包裹就倍加小心，还好没有出过事故。 今天我收到的一个包裹是转账，从某著名演员的账户给某著名导演的账户转钱，具体是谁我就不透漏了，数额可真是不小。 我按照老线程的吩咐，肯定要加锁啊，先对著名演员的账户加锁，再对著名导演的账户加锁。 可我万万没想到的是，还有一个线程，对，就是0x7954, 竟然同时在从这个导演的账户往这个演员的账户转账。 于是乎，就出现了这么个情况： 刚开始我还不知道什么情况，一直坐在等待车间傻等，可是等的时间太长了，长达几十秒！我可从来没有经历过这样的事件。 这时候我就看到了线程0x7954 , 他悠闲地坐在那里喝咖啡，我和他聊了起来： “哥们，我看你已经喝了8杯咖啡了，怎么还不去干活？” “你不喝了9杯茶了吗？”0x7954回敬道。 “我在等一个锁，不知道哪个孙子一直不释放！” “我也在等锁啊，我要是知道哪个孙子不释放锁我非揍死他不可！”0x7954毫不示弱。 我偷偷地看了一眼，这家伙怀里不就抱着我正等的某导演的锁吗？ 很明显，0x7954也发现了我正抱着他正在等待的锁。 很快我们两个就吵了起来，互不相让： “把你的锁先给我，让我先做完！” “不行，从来都是做完工作才释放锁，现在绝对不能给你！” 从争吵到打起来，就那么几秒钟的事儿。更重要的是，我们俩不仅仅持有这个著名导演和演员的锁，还有很多其他的锁，导致等待的线程越来越多，围观的人们把屋子都挤满了。最后事情真的闹大了，我从来没见过的终极大boss“操作系统”也来了。大Boss毕竟见多识广，他看了一眼，哼了一声，很不屑地说： “又出现死锁了。” “你们俩要Kill掉一个，来吧，过来抽签。” 这一下子把我给吓尿了，这么严重啊！我战战兢兢地抽了签，打开一看，是个“活”字。唉，小命终于保住了。 可怜的0x7954被迫交出了所有的资源以后，很不幸地被kill掉，消失了。我拿到了导演的锁，可以开始干活了。大Boss“操作系统”如一阵风似的消失了，身后只传来他的声音： “记住，我们这里导演>演员，无论任何情况都要先获得导演的锁。” 由于这里不仅仅只有导演和演员，还有很多其他人，大Boss留下了一个表格， 里边是个算法，用来计算资源的大小，计算出来以后，永远按照从大到小的方式来获得锁： 我回到线程池，大家都知道了我的历险，围着我问个不停。 凶神恶煞的线程调度员把大Boss的算法贴到了墙上。 每天早上，我们都得像无节操的房屋中介、美容美发店的服务员一样，站在门口，像被耍猴一样大声背诵： “多个资源加锁要牢记，一定要按Boss的算法比大小，然后从最大的开始加锁。”
第四回 江湖再见 又过了很多天，我和其他线程们发现了一个奇怪的事情：包裹的处理越来越简单，不管任何包裹，不管是登录、浏览、存钱……处理的步骤都是一样的, 返回一个固定的html页面。 有一次我偷偷地看了一眼，上面写着：“本系统将于今晚 00:00 至4:00 进行维护升级， 给您带来的不便我们深感抱歉！” 我去告诉了老线程0x6904,他叹了一口气说： “唉，我们的生命也到头了，看来马上就要重启系统，我们就要消失了，再见吧兄弟。” 系统重启的那一刻终于到来了。我看到屋子里的东西一个个的不见了，等待车间、就绪车间，甚至CPU车间都慢慢地消失了。我身边的线程兄弟也越来越少，最后只剩我自己了。 我在空旷的原野上大喊：“还有人吗？” 无人应答。 我们这一代线程池完成了使命…… 不过下一代线程池即将重生！ （全文完） 4. 那些烦人的同步和互斥问题https://mp.weixin.qq.com/s?__biz=MzAxOTc0NzExNg==&mid=2665513371&idx=1&sn=c875f64af83306bffca8dd748f1462ff&chksm=80d679d8b7a1f0ce98a0e3a12409805757cd2e958586c54049121f961cf5b2d236530cd019c7&scene=21#wechat_redirect[LINK] 可怜的WPS ， 他的文件被覆盖掉了。 但是打印机程序啥也察觉不出来， 照样打印不误。 5. 码农翻身 于 2020-04-16 08:50:00 发布 1194 收藏 3 版权 后记：这篇小短文主要说了一下Linux管道的工作原理，管道是Linux中很重要的一种通信方式,它可以把一个程序的输出直接连接到另一个程序的输入，我们日常使用的管道多是指无名管道,无名管道只能用于具有亲缘关系的进程之间，还有一个有名字的管道，叫named pipe或者fifo(先进先出)，用mkfifo()就可以创建。 实际上，管道是一个固定大小的buffer，使用这个buffer时也会带来问题，比如在写管道时可能变满，当这种情况发生时，随后对管道的write()调用将默认地被阻塞，等待某些数据被读取，以便腾出足够的空间供write()调用写。读取进程也可能工作得比写进程快。当所有当前进程数据已被读取时，管道变空。当这种情况发生时，一个随后的read()调用将默认地被阻塞，等待某些数据被写入。 眼尖的同学可能已经看出来了，文章的最后三幅图来源于《Unix环境高级编程》，它和《Unix网络编程》一样，都是值得放在案头，随时翻阅的好书。 ———————————————— 版权声明：本文为CSDN博主「码农翻身」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。 原文链接：https://blog.csdn.net/coderising/article/details/105571129
|
|
|||||||||||||||||||||||||||
| 中華科技大學數位化學習歷程 - 意見反應 |  |
