erl_0020 《面对软件错误构建可靠的分布式系统》读书笔记001 “面向并发COPL”

  在现实世界中,顺序化的(sequential)活动非常罕见。当我们走在大街上的时候,如果只看到一件事情发生的话我们一定会感到不可思议,我们期望碰到许多同时进行的活动。

  如果我们不能对同时发生的众多事件所造成的结果进行分析和预测的话,那么我们将会面临巨大的危险,像开车这类的任务我们就不可能完成了。事实上我们是可以做那些需要处理大量并发信息的事情的,这也表明我们本来就是具有很多感知机制的,正是这些机制让我们能够本能地理解并发,而无需有意识地思考。
  然而对于计算机编程来说,情况却突然变得相反。把活动安排成一个顺序发生的事件链被视为是一种规范,并认为在某种意义上讲这样更简单,而把程序安排成一组并发活动则是要尽可能避的,并常常认为会困难一些。
  我相信这是由于几乎所有传统的编程语言对真正的并发缺乏有力支持造成的。绝大多数的编程语言本质上都是顺序化的;在这些编程语言中所有的并发性都仅仅由底层操作系统来提供,而不由编程语言来提供。在本论文中,我展现了这样的一个世界,其中并发是由编程语言来提供的,而不是由底层操作系统来提供。我把对并发提供良好支持的语言称为面向并发的语言(Concurency Oriented Language),简称 COPL。

 COPL 可以由如下 6 个特性来刻画:
  1. COPL 应当支持进程。每一个进程应该可以看作是一个自包含的虚拟机器(self-contained virtual machine)。
  2. 运行在同一机器上的各个进程应该被高度隔离。一个进程中的故障不能对其他进程产生副作用,除非这种交互在程序中被明确化。
  3. 每个进程必须用一个唯一的、不可仿造的标识符来标识。我们称之为进程的 Pid。
  4. 进程之间没有共享状态。进程只通过消息传递来进行交互。只要知道进程的 Pid,就可以向它发消息。
  5. 消息传递被认为是不可靠的,无传输保障的。
  6. 一个进程应当可以检测另一个进程中的故障,并可以知道发生故障的原因。
  值得注意的是,COPL 提供的并发性一定是真正的并发性,因此以进程的形式存在的对象都是真正并发的,进程间的消息传递也是真正的异步消息,而不像许多面向对象语言中一样是通过远程过程调用(remote procedure call)来冒充。

时间: 2024-10-08 22:25:59

erl_0020 《面对软件错误构建可靠的分布式系统》读书笔记001 “面向并发COPL”的相关文章

面对软件错误构建可靠的分布式系统(阅读笔记)

阅读笔记 joe Armstrong 段先德 译 核心问题:如何在存在软件错误的情况下编写具有合理行为的软件 ,如何避免像死锁.死循环等问题 ERLANG的世界观,一切皆进程.将任务分离成层次化的一系列任务,强隔离的进程负责来执行每个具体化的任务,进程之间不共享状态(实际上ETS跨越了这个准则). 只能通过消息传递来通信,必须注意进程消息的堵塞问题 工作者和监督者构成一个完整的系统,监督者的作用就是监控整个系统的运行状况.并对突发情况进行可靠的处理. behaviour库的设计思想就是将程序的并

项目管理学习——《构建之法》读书笔记

最近终于有时间来读读书了.买了<构建之法>已经一年多了,这次静下心来读完了,收获很大.现在想起自己在上大学的时候学习软件工程是机械工业出版社出版的一本外国书籍的翻译版本,当时由于对于整个行业没有太大的感触,而这本书又全部由专业术语和定义组成,所以当时的课是相当痛苦.而老师通过的这门课程的方式又由各种理论知识考试为准,所以当时学习感觉相当“鸡肋”. 好的地方: 1,情景式.对话式对白,有趣易读.这点非常喜欢,很多实际中碰到的问题在这里可以重现.比如:每日构建,在实际开发中,就会由于各种原因导致不

《构建之法》读书笔记01

今天阅读了邹欣老师的<构建之法:现代软件工程>的第一章,也回想起了我之前对于软件和硬件的一些思考,在这里一并总结. 首先谈软件工程,在计算机技术刚刚发明的时候,跟其他的行业一样,肯定是没有工程这个概念的.肯特.柯西做热气球的时候如果还要想想这个热气球除了飞上天,还要不要能在上面做个饭睡个觉啥的(需求分析),要不要绘制模型,然后规范加工生产(构建管理),进而涉及到热气球的版本--什么时候发布热气球2.0(版本控制),然后怎么把我的热气球推广出去(推广),除非他对飞上天特别狂热,不然面对这么多繁杂

《构建之法》读书笔记二

这周读了<构建之法>的第二章.第二章主要讲到了个人技术和流程. 软件是由多人合作完成的,不同人员的工作相互有依赖关系.一个团队需要一定的流程来管理开发活动,每个工程师在软件生命周期所做的工作也应该有一个流程.所以就引进了一个新的名词叫做PSP--个人软件开发流程.但是要做到每个人的模块的质量得到稳定.量化的保证,单元测试就是一个很有效的解决方案.我们可以用vsts写单元测试,这是一个新的软件,我从来没有接触过,所以也不会用.只看了一下代码. 好的单元测试应该准确.快速地保证程序基本模块的正确性

《构建之法》读书笔记

这次个人阅读选择的书籍为<构建之法:现代软件工程>(邹欣 著).我们这门课程也参考了很多这本书的结构.内容与方法,读这本书,既是对学过知识的复习和细化,也是对以后课程的预习. 下面总结了几个阅读过程中理解有困难或疑问的point,有的是细节,有的是大的方法.然后在网上查找学习了相关内容,与大家分享. 1.  第4章 两人合作 —— 4.3 代码设计规范 —— 4.3.3 错误处理 此处提到了“断言”的概念,但着墨不多,介绍简略. 那么问题来了,挖掘机……不是,断言是什么? 编写代码时,如果程序

《构建之法》读书笔记3

太久没读专业性书籍了.感觉大脑像一片亟需雨露的干渴沙漠,看到很多观点都觉得好有道理,想要拼命点头.读书就是慢慢梳理自己已有的.潜行的.杂乱无章的思绪的过程吧. [3.1] 工程师的成长: 积累软件开发相关的知识,提升技术技能(如对具体技术的掌握,动手能力):积累问题领域的知识和经验(例如:对医疗或金融行业的了解):对通用的软件设计思想和软件工程思想的理解:提升职业技能(职业技能包括:自我管理的能力,表达和交流的能力,与人合作的能力,按质按量完成任务的执行力): 实际成果. 长时间稳定而按时的交付

《构建之法》读书笔记05

团队有一些共同的特点:有一致的集体目标,成员之间有各自的分工,合作完成任务.团队一开始可能是"一窝蜂模式",都想写出好的软件,但是没有各自的分工,一般不会这种模式不会存活太久.慢慢会演化成其他模式,比如"主治医师模式",本来是不错的模式,但是在学生身上退化为了一个学生干活,其余打酱油的情况.还有比如明星模式,社区模式,业余剧团模式等,当然其中不乏一些好的模式,秘密团队,交响乐团模式,功能团队模式等. 学校里面的软件工程专业的学生可能是"写了再改模式&quo

记软件构建之法的读书笔记

什么是软件工程? 软件工程与计算机科学有什么关系? <构建之法:现代软件工程>这本书的绪论主要就是讲解这两个问题.软件工程是把系统的.有序的.可量化的方法应用到软件的开发.运营和维护的过程.它包括:软件需求分析.软件构建.软件测试和软件维护等多个领域.做一个合格的软件工程师,并不仅仅局限于你会多少种语言,是否会用C++写“Hello World”的程序,你还要清楚软件如何构建以及在软件构建之中不厌其烦的去做那些用户使用率为百万分之一,但却不可或缺的功能.程序是基本功,但是在算法和数据结构之上,

《构建之法》读书笔记一

本周先看了<构建之法>的第一章. 这一章介绍的理论和知识点有计算机科学的领域.软件的特性.软件工程.软件工程与计算机科学的关系,还向我们详细介绍了软件工程的定义与组成部分. 其中有三个推论: 程序=数据结构+算法 软件=程序+软件工程 软件企业=软件+商业模式 由此可知,程序(算法.数据结构)是基本功,但是在算法和数据结构之上,软件工程决定了软件的质量. 而后课本又讲到了"软件是什么"这一个问题上. 通过阅读我了解到了软件的特殊性,它的开发过程的难点就是在复杂性.不可见性.