但是这给应用带来了负担。如果一个应用程序有多个线程(分布或不分布在多个CPU核上),在它们都要读取同一个cell而又有某个线程要写该cell时，那么大家就都要被挂起来，直到这个写操作完成。整个应用程序在CPU使用(或者说效率)上就大大打了折扣。

如果这只是一个桌面程序(例如记事本),大概没人会说什么。但如果这是个服务器程序(例如wwW Service),那么整个网络、所有的会话就都处于等待状态了，但同时，服务器的CPU占用可能会远远小于1%!

解决问题的终极方法，就是不解决这个问题。既然写cell带来了问题，那么我们就“不写cell”。我们由前面所有讲述的内容开始倒推，问题根本是由“命令式语言”这个编程范式本身决定的：用算法改变数据。

【所以我们回到了原始的问题：如果算法不改变cells(数据/状态/变量)呢?】

【附录二】

继承与混合，略谈系统的构建方式面向对象系统有三种对象的继承方式，即原型、类和元类。这三种方式都可以构建大型对象系统。在后续讨论之前，我们先在名词概念上做一些强调。所谓“对象系统",是指由“一组对象构成的系统",这些对象之间存在或不存在某种联系，但通过一些规则组织起来。所谓“面向对象系统",是指以上述“对象系统”为基础延伸演化的系统，新系统满足前对象系统的组织规则。yipindushu.com

所谓“对象系统的三个要素”——继承、封装与多态，即是上述组织规则的要件。孟岩同学从C/C++出发②,从另一个侧面谈论对象系统，所持的观点我相当认可。他指出，"对象范式的基本观念中不包括继承、封装与多态",这一观点有其确切的背景与思考方法，值得一谈。

我们在这里要讨论的是“对象系统”,即对象是如何组织起来的问题。在这个问题上，组织规则之一就是“继承”。JavaScript中基本的继承模型是原型继承，其特点是“新对象实例的特性，复制自一个原型对象实例”。Qomo以及其他一些项目，通过语言扩展的方式，在JavaScript上添加了类继承的模型，其特点是“对象构建自类，类是其父类的一个派生",这里的“派生"与“特性复制”有潜在的关系，即子类的特性也复制自父类。正是由于“派生”其实是“特性复制”的一种形式，所以事实上Qomo中的类继承是通过原型继承来实现的，因为原型继承本质上也就是“特性复制”。

无论是原型继承、类继承还是这里没有进一步讨论的元类继承，继承的最终目的都是构建一个“对象系统",而不是“系统”。这一个措辞上小小的区别，有着本质上的深刻意义，这也是我提及孟岩的那一篇文章的原因。通常由“继承”入手理解的“对①节选自博客文章“继承与混合，略谈系统的构建方式”(2010年12月),文章讨论了对“基于对象系统进行系统构建”的认识与实现。②参见孟岩的博客文章"function/bind的救赎":http://blog.csdn.net/myan/article/details/5928531。

象系统"其实是静态的，以至于我们在面向对象系统开发的最后一步，仍然需要框架来驱动它。例如TApplication.Run(),或者类似的new Application()等。继承所带来的，主要仍然是指对象系统的组织性，而非其运行过程中的动态特性。

于是我们通过更多类或其他对象系统，来将一个系统的动态特性静态化。例如将对象之间的交互关系抽取出来，变成控制类。我们做这些事情的目的，仅仅是因为我们约定了对象系统的组织规则，要面向这个对象系统开发，也必然满足(或契合)这一组织规则。组织规则限定了我们构建系统的方式——继承、封装与多态，这在一定程度上说是“对象系统构建”的一个方案，并非“系统构建”的方案。而孟岩在文章中所讨论的，正是“系统构建”的问题。所以孟岩提出两点：□程序是由对象组成的；□对象之间互相发送消息，协作完成任务。

其中第一条，是对象系统的基本特性，是谓系统成员；第二条，是对象系统如何演进为系统的特性，是谓系统通信。一个系统的约束，既包括其成员(以及成员的组织规则),也包括成员间的通信。