D
Published on
· Last modified on
· Public

并发策略:多线程编程(译文)

相比于编程领域的其他问题,多线程编程显得尤为困难。

– 多线程的环境使我们的程序非线性。没有人知道系统下一刻会执行哪一条语句。不幸的是,绝大多数程序(比如C++,Java)是线性地编写的:下一条语句总是在上一条执行完后执行。更严重的是,我们还在学习编程时就被灌输了,程序是线性执行的这一观点。因此,在多线程的编程范式上,绝大多程序员举步维艰。

– 多线性编程几乎是在多个方向上,爆炸般地撑大了程序的状态空间。我们很难在面对海量的程序状态的可能结果的情况下,仍然清晰地理解一个多线程程序,更毋论编写和测试程序。我们也很难去测试所有可能的状态,因为这些状态实在是太多了。

– 多线程编程使一个确定性的程序变为非确定性。这引入了更多测试上的问题。

– 糟糕的并发策略会显著地拖慢程序的性能,在一些并发策略的运行成本特别高昂的系统上(例如Windows),这个问题更为严重。

– 在多线程编程时,我们可用的debug工具非常少。如果找不到趁手的debug工具,真不如干脆当做自己没有任何调试工具。因此,忘掉调试器这回事吧。

– 很多语言,特别是C++,根本不支持多线程编程。Java在多线程上倒是有着出彩的表现,原因是Java实现了monitor机制。然而,这些机制并非一劳永逸的防弹衣,它们也并非在任何情形下都适用。

– 很多系统提供了内建的通过简陋的C调用实现的并发设计。然而,采用面向对象的并发实现会显得好的多,特别是在C++中,你可以控制构造/析构函数的加锁/解锁,从而达成预期的平衡。当前我成功地实现了这一点,并且我的C++环境有着一些非常棒的支持并发的对象。有趣的是,这些优秀的并发需要程序员自己来实现,而非囊括在语言特性中,我完全可以用功能等同的第三方代码来替换它们,从而测试我的多线程代码。

– 目前有许多著名的,广泛验证过的模式可用于处理并发问题,比如Exception Handling和Resumable Exception。报错往往相对地更多集中于程序代码中(debug是一个非常有趣的过程),所以异常检验尤为重要。异步故障引入了一些全新的故障类别,比如死锁,竞争条件,线程的报错处理和live lock。这些都错误通常都非常地模糊,你既不知道该再哪里处理这些错误,也不知道让谁来定义处理的代码。

原文地址

Sign in or Sign up Leave Comment