当前位置:Linux教程 - Linux综合 - 来自 e-BIT 的珍品:双 if 魔符

来自 e-BIT 的珍品:双 if 魔符

  如果您发现您的代码 99.99% 的时间在单 CPU 上运行,但是当您按比例增加到两个或更多个 CPU 时,它很快就会崩溃,那么这一珍品正适合您。 这一问题不仅与 Java 代码在一个对称多处理器(symmetric multiple processor,SMP)平台上运行的复杂程度有关,还与管道技术对“受保护的(protected)”代码的影响有关。尽管您的代码应该高效而且一致始终都很重要,但是由于 SMP 这样的平台将夸大存储模型中的一致性问题,因此,当您的应用程序在 SMP 平台上运行时尤其是如此。 虽然双 if 子句是解决多线程应用程序所带来的问题的一般方法,但它使您遇到“弱一致性”模型(CPU 管道技术、预测执行(speculative execution)等等)所带来的问题(尤其是关于 SMP 系统)。因此,这个珍品简而言之就是:如果您的应用程序将在 SMP 系统上运行,那么请不要在您的代码中使用双 if 逻辑。现在,让我们仔细看一下这个问题的原因和机理。 双 if 逻辑 首先,请考虑一下把指针指向资源的下列代码,其中 flag 表示有无该资源: IF flag == 0 { // no resource set flag acquire resource set pointer to resource } ELSE set pointer to resource 如果这段代码是可重入的(即,可以由多个线程运行它),那么它是非常危险的。请考虑一下如果一个线程在 if 子句的中途,此时另外一个线程发现 flag 已经被设置了,于是它就试图去设置一个指针指向第一个线程还未分配的资源,结果会怎样呢?幸运的是,这个问题很容易纠正,如下所示: IF flag == 0 { // no resource acquire resource ----- A set pointer to resource set flag } ELSE set pointer to resource 但是,现在我们又发现另外一个问题:一个线程阻塞在 A 点,另一个线程却因发现 flag 被设为 0 而继续执行。在这种情况下,这两个线程都执行同一段代码分配资源 — 这根本不是我们所希望的!然而,解决方法又是众所周知:我们只要在执行获取资源的代码时,封锁所有其它线程,如下所示: ENTER LOCK IF flag == 0 { // no resource acquire resource set pointer to resource set flag } ELSE set pointer to resource LEAVE LOCK (请注意我使用了 LOCK 这一术语来保持示例简单。当然,在 Java 代码中是用 synchronize 子句内的同步代码来表示它)。 现在我们的代码是线程安全的,但还不是高效的。获取锁(或 Java 术语中的管程(monitor))需要很多时间,而且锁中的代码比我们需要的要多。为了纠正这一点,我们把代码改写成下面这样: IF flag == 0 { // no resource ----- A ENTER LOCK acquire resource set pointer to resource set flag LEAVE LOCK } ELSE set pointer to resource 这几乎奏效了,但是我们又引入了前面的问题,一个线程在 A 点被中止,而另一个线程插入进来,因此造成了 CPU 的混乱。为了纠正这一点,我们使用著名的双 if 子句: IF flag == 0 { // no resource ----- A ENTER LOCK IF flag == 0 acquire resource set pointer to resource set flag ELSE set pointer to resource LEAVE LOCK } ELSE set pointer to resource 通过添加双 if 子句,我们已经尽了最大努力使代码线程安全而且高效。许多高级编程技术方面的书中都推荐使用双 if 逻辑来解决线程争用。但是双 if 逻辑在多个线程可以同时执行的 SMP 机器上并不安全。 您会说,可是某一时刻在“锁住的”那部分代码中只会有一个线程,那么会出什么问题呢?很多!这就是把这一技巧叫做“双 if 魔符”的原因所在。
[1] [2] 下一页 

双 if 魔符请考虑一下管道技术对上面这段代码的影响: 由于 CPU 看不到任何依赖,所以可以以任何次序执行 if 子句里的代码。这会影响到下面用 * 标出的指令。 如果 flag 被设为 0,那么与先计算“flag”再计算 flag 非 0 情况下的指针相比,计算指针(可能会是垃圾)并抛掉它可能是更高效的做法。所以,CPU 可以采用管道技术处理下面用 ** 标出的指令。 以下又是这些代码,为说明上述观点而加上了标记: **IF flag == 0 { // no resource ENTER LOCK IF flag == 0 *acquire resource *set pointer to resource *set flag ELSE set pointer to resource LEAVE LOCK } ELSE **set pointer to resource 尽管这似乎有点奇怪,但上面的代码可能会象下面这样执行: **set pointer to resource **IF flag == 0 { // no resource ENTER LOCK set pointer to resource IF flag == 0 *set flag *acquire resource ----- A *set pointer to resource ELSE LEAVE LOCK } ELSE 正如您所见到的,我们很敏感的代码仍在锁中,但是现在在分配资源之前设置 flag。因此,请想象一下线程 A 正在 A 点附近执行,此刻另外一个线程到来了。在 SMP 机器上,第二个线程可以在另一个 CPU 上与第一个线程同时执行;这个线程看到 flag 没有被设置成 0(因为它在锁的外部),它可以继续把指针指向未分配资源 — 上当了! 此外,即使代码按我们所写的执行,我们仍然没有免除灾难,原因在于 CPU 可以采用管道技术处理以上用 ** 标出的代码: 1. 线程 A 进入锁住的那部分代码。 2.线程 B 对第一个 if 语句求值并计算指针的值(在最后的 else 子句中)。 3.线程 B 得到“指针”(由于线程 A 还没有指定它,所以是垃圾)的值。 4.在线程 A 完成并解锁的同时,线程 B 将计算第一个 if 的值。 5.解锁导致“flag”的值被清除(意味着线程 B 在它的高速缓存中具有的任何值都是无效的)。 6.线程 B 计算好第一个 if 子句的值,当然,现在它发现值为 true。 7.现在线程 B 使用前面那个是垃圾的指针值。 这就是 Java 双 if 魔符。虽然其它的语言(比如 C/C++)让您通过使用语言本机功能强制执行的次序来解决这个问题,Java 语言却不行。为了安全的执行上述示例,您必须把所有代码封装在一个 synchronize 子句中,或者寻找另外一种写法。

(出处:http://www.sheup.com)


上一页 [1] [2] 

正如您所见到的,我们很敏感的代码仍在锁中,但是现在在分配资源之前设置 flag。因此,请想象一下线程 A 正在 A 点附近执行,此刻另外一个线程到来了。在 SMP 机器上,第二个线程可以在另一个 CPU 上与第一个线程同时执行;这个线程看到 flag 没有被设置成 0(因为它在锁的外部),它可以继续把指针指向未分配资源 — 上当了! 此外,即使代码按我们所写的执行,我们仍然没有免除灾难,原因在于 CPU 可以采用管道技术处理以上用 ** 标出的代码: 1. 线程 A 进入锁住的那部分代码。 2.线程 B 对第一个 if 语句求值并计算指针的值(在最后的 else 子句中)。 3.线程 B 得到“指针”(由于线程 A 还没有指定它,所以是垃圾)的值。 4.在线程 A 完成并解锁的同时,线程 B 将计算第一个 if 的值。 5.解锁导致“flag”的值被清除(意味着线程 B 在它的高速缓存中具有的任何值都是无效的)。 6.线程 B 计算好第一个 if 子句的值,当然,现在它发现值为 true。 7.现在线程 B 使用前面那个是垃圾的指针值。 这就是 Java 双 if 魔符。虽然其它的语言(比如 C/C++)让您通过使用语言本机功能强制执行的次序来解决这个问题,Java 语言却不行。为了安全的执行上述示例,您必须把所有代码封装在一个 synchronize 子句中,或者寻找另外一种写法。

(出处:http://www.sheup.com/)


上一页 [1] [2] [3]