ITPub博客

首页 > Linux操作系统 > Linux操作系统 > [转载]来自 e-BIT 的珍品: 双 if 魔符

[转载]来自 e-BIT 的珍品: 双 if 魔符

原创 Linux操作系统 作者:dinner1007 时间:2019-02-28 15:00:07 0 删除 编辑

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


如果您发现您的代码 99.99% 的时间在单 CPU 上运行,但是当您按比例增加到两个或更多个 CPU 时,它很快就会崩溃,那么这一珍品正适合您。这一问题不仅与 Java 代码在一个对称多处理器(symmetric multiple processor,SMP)平台上运行的复杂程度有关,还与管道技术对“受保护的(protected)”代码的影响有关。尽管您的代码应该高效而且一 致始终都很重要,但是由于 SMP 这样的平台将夸大存储模型中的一致性问题,因此,当您的应用程序在 SMP 平台上运行时尤其是如此。

如果您发现您的代码 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 魔符”的原因所在。




回页首


双 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 子句中,或者寻找另外一种写法。

来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/374079/viewspace-130120/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论

注册时间:2018-08-23

  • 博文量
    1714
  • 访问量
    1294743