冲冲冲

 豁然开朗~

引用

POSA2读书笔记（二）

呵呵，距离第一篇已经过了半年了……这本书其实翻完已经很久了，但是实践中没有使用到的东西总是一知半解，写出来会误导大众，所以还是不写的好。

 

今天在为Cindy 3.0a1中并发模型设计头痛的时候，翻了翻这本书中的相关模式，突然有种豁然开朗的感觉：）

 

Half-Sync/Half-Async：这个模式是从Cindy 1.x一直沿用下来的模式，我估计也是基于NIO的网络应用里面最常用的并发模型。简单的用伪码说：

while (select() > 0) {
    getReadyEvents();
    deactiveEvents();
    addEventsToQueue();
}

网络IO线程不停的select，并把发生的事件添加到某个队列；若干个工作线程并行的从该队列中取的相应的事件，并分发给应用。网络IO线程是串行化的，而工作线程是并行的，所以这个模式就叫半同步/半异步模式。

 

Leader/Followers：这是今天才豁然开朗的模式：） 在上面的半同步/半异步模式中，瓶颈主要有三处：

• 动态内存分配。网络IO线程把事件添加到队列，工作线程从队列中取事件，不停的有添加删除操作，队列大小在不停的发生变化。
• 多同步操作。在对队列进行添加和删除操作时需要对队列进行同步（或者是在队列内部进行同步），同时各个工作线程之间从队列中取相应事件时需要同步。
• 线程切换：需要不停的在网络IO线程和各工作线程之间做语境切换。比如假设首先所有的工作线程都处于等待状态，这时来了某一个事件，工作线程A被唤醒，去处理该事件；然后又来一个事件，工作线程B被唤醒，去处理该事件；A工作完又回到等待状态，然后又被唤醒……

那么领导/追随模式是怎么样来避免上面的这三个瓶颈呢？

首先领导线程在通过select得到了许多的响应事件，然后领导线程把其中一个从selector上移除，并把一个追随线程提升为领导线程，然后自己就变成了工作线程处理该事件，等到事件处理完成后再变成追随线程或领导线程（如果结束时已经没有可用的领导线程的话）。

这个模式不需要进行动态内存分配，同步操作也比上一个模式少很多，由于领导线程直接变成工作线程处理事件，最大程度的减少了线程切换，所以上面那三个瓶颈都能够得到很好的解决。但是这个模式也有相应的缺点：实现复杂，不像半同步/半异步模式能非常简单的实现。所谓有得必有失呀：）

 

这里可以做一个简单的比喻为两种模式做一下总结。场景是把一堆书从A地经过B地搬到C地（我想不到其他好的例子）。

如果是半同步/半异步模型的话，就是有一个人负责把书从A地搬到B地，其余的人在B地等着，一旦B地书来了，就把书再搬到C地。

如果是领导/追随者模型的话，则是所有的人都在A地排队等待，每个人搬一本送到C地，然后回来排到队伍的最后面。（领导/追随者模型并没有规定次序，所以回来后不一定是排在队伍的最后面，反而是非常有可能排在队伍的第二个位置，这样可以提升系统性能）

 

A software methodology is the set of rules and practices used to create computer programs.
软件方法就是用来编写计算机程序的一套规则和惯例。

A heavyweight methodology has many rules, practices, and documents.
重量级方法具有很多规则、惯例、和文档。

It requires discipline and time to follow correctly.
正确地遵循它们需要训练及时间。

A lightweight methodology has only a few rules and practices or ones which are easy to follow.
轻量级方法仅具有很少的一些规则和惯例，或者说，这些规则和惯例遵守起来很容易。

In the late 1960s and early 1970s it was common practice for computer programmers to create software any way they could.
在20世纪的60年代后期以及70年代早期，计算机程序员随意使用他们能够使用的任何方式来写软件是件非常常见的事情。

Many programmers excelled at creating software too complex for anyone to understand.
很多程序员竞相写出复杂得对于任何人来说都无法理解的软件。

At that time it was a miracle if a program ran without any bugs.
如果有一个程序，它没有任何的bug，在那时可称得上是个奇迹。

Making computers useful was considered a worthy quest and not unlike an adventure into the old west.
大家都认为让计算机有用武之地是个有价值的追求，不能说不象老早的西部冒险之旅。

In 1968 Edsger Dijkstra wrote a letter to CACM entitled GOTO Statement Considered Harmful.
Edsger Dijkstra于1968年给CACM（应该是Communication of the Association for Computing Machinery: 计算机器 协会 通信）写了一封题为“GOTO语句其实有害”的信。

The central ideas of software engineering were being born.
自此，软件工程的主要概念开始成型。

At that time we believed that bigger, more disciplined methodologies would help us create software with consistent quality and predictable costs.
那时大家认为更全面、更严谨的方法可以帮助我们创建品质可靠、成本可准确估计的软件。

The lawless cowboy coders were being reined in.
无法无天、牛仔式的编码者们被悬崖勒马。

The 1980s were good times for computer programmers.
20世纪80年代正是计算机程序员们的好时光。

We had a few rules and practices to create software that was far superior in quality to what we were creating only a few years earlier.
我们有了一些规则和惯例。从质量上讲，我们这时写的软件远远优于仅仅是写于几年前的软件。

It seemed like if we could just create enough rules to cover the problems we encounter we could create perfect software and be on time.
似乎可以认为：如果能够建立足够多的规则，可适用于所有能够碰到的问题，我们就能够写出完美的软件，并且还能按时完工。

We added more and more rules and practices to cover all the potential problems.
于是乎就有了越来越多的、适用于所有潜在问题的规则和惯例，

Now in the 21st century we find these rules are hard to follow, procedures are complex and not well understood and the amount of documentation written in some abstract notation is way out of control.
现已进入了21世纪，我们发现，这些规则遵守起来非常困难，其过程很复杂，也没有得以透彻地理解；使用各种抽象符号写就的、海一样的文献犹如脱缰的野马纷至沓来。

Trying to come up with a bigger and better methodology was like a California gold rush; everyone headed west only to be disappointed.
大家热火朝天，都想提出更全面、更好的方法，跟California（加利福尼亚，加州）淘金热似的真有一比；每个到了西部的人却都很失望。

We created software to help us create software.
我们写出了能够帮助我们写软件的软件。

But this quickly got out of control and dreadnought CASE tools were born.
但是，这很快就乱了套，各种重磅炸弹似的CASE工具迎面而来。

These tools, originally created to help us follow the rules, are too hard to use themselves.
这些工具原本是用来帮助我们遵守规则的，可它们用起来很是困难，简直都没法用。

Computer programmers find it necessary to cut corners and skip important practices to stay on schedule.
要按时完工，计算机程序员发现他们必须抄近路，忽略一些重要的惯例。

No one is actually following the heavy methodologies we have handcuffed ourselves with.
实际上没有一个人真的遵守那些曾经用来自缚的重量级方法。

The cowboys have returned and we find ourselves back at the OK Corral.
牛仔又回来了，我们回到了俄克拉荷马州（译者注：俄克拉荷马州是偶对OK的猜测，因为偶了解到俄克拉荷马州曾经是往美国西部输出劳工的一个大州，但可能有误，呵呵）的畜栏之中。

When programmers ignore the rules of their methodology they are instinctively moving away from heavyweight methodologies and back toward an earlier, simpler time of lightweight methodologies when a few rules were enough.
当程序员忽略了他们的方法中的规则时，他们（实际上是）本能地脱离重量级方法，回到了早期较为简单的、轻量级方法时代，很少的规则便够了。

But we don't want to forget what we have learned.
可我们并不想忘记我们已经学到的东西。

We can choose to keep the rules that help us create quality software and throw away those that hinder our progress.
我们可以把（能够）帮助我们写出高质量软件的规则保留下来，而摒弃哪些阻碍我们前进的哪些规则。

We can simplify those rules that seem too complex to follow correctly.
我们可以对那些复杂得难以遵循的规则进行简化。

We don't want to return to the early days of cowboy coding when there were no rules at all.
我们也不想回到早期根本没有任何规则可言的牛仔式编码时代。

But instead let's stop at just enough rules to keep our software reliable and reasonably priced.
而是让我们止于足够能使我们的软件可靠、适度定价的规则吧。

Instead of cowboy coders we have software sheriffs; working together as a team, quick on the draw, armed with a few rules and practices that are light, concise, and effective.
我们接受软件行政长官而不要牛仔式的编码者；我们作为团队工作在一起，反应敏捷，仅仅用那些轻量级的、简练的和有效的规则和惯例把我们武装起来。

Extreme Programming (XP) is one of several new lightweight methodologies.
极度编程（XP）就是若干这种新式的、轻量级的方法之中的一种。

XP has a few rules and a modest number of practices, all of which are easy to follow.
XP具有若干规则和适当数量的惯例，且所有这些遵守起来都很容易。

XP is a clean and concise environment developed by observing what makes software development go faster and what makes it move slower.
XP是一种干净简洁的环境，它形成于对到底是哪些东西能够加速软件开发，以及哪些东西却起着减速作用的观察。

It is an environment in which programmers feel free to be creative and productive but remain organized and focused.
它是一种使程序员能够自由发挥其创造力和生产力，却同时有保持组织性和凝聚力的环境。