线程基础之JAVA和C++0x的特性

译文连接   译文地址  译者：衣着时   校对：丁一    （有兴趣参与试译或校对的同学，请加入并发网试译者QQ群：369468545）

JAVA特性

JAVA线程通常是一个带有run()方法的java.lang.Thread的子类，然后调用这个子类对象的start()方法。我们之前定义过，数据竞争是因为两个线程同时访问内存单元，在JAVA中，内存单元是一个对象字段或数组元素。

由于JAVA旨在支持运行不受信任代码作为受信任的应用程序的一部分，必须限制不受信任代码的数据争用造成的破坏。因此不允许数据争用的任意行为，所以，JAVA语言规范包含了一个复杂的规则集，用来定义线程间的共享对象的行为，包括数据争用的行为，这些规则的影响甚至专家都觉得惊讶。然而这些规则保证了免除数据争用的程序的连续一致，对于程序来讲是个更加容易的模型。

如上所述JAVA的数据争用定义的可替换的定义是，并发冲突操作必须被阻止同时出现通过执行相同的线程，或者引入强制实施线程间的顺序的同步变量。如果采用了这些机制，就可以说一个内存操作发生在另一个内存操作之前。因此不会发生交叉存储。这基本相当于我们的定义。

在几乎所有情况下,Java程序应该避免数据竞争,和依赖顺序一致性。事实上附加的保障数据竞争问题只有三种情况:

1.对于编译器，必须保护它们。

2.对于尤其安全的敏感的代码，作者需要限制不受信任的“沙箱”代码引起的破坏。

3.对于极其性能敏感代码的富有经验的作者来讲，使用同步变量的格外代价太高。尽管这样的代码存在于java.util.concurrent类库里，我们还是期望比较少的程序员写这样的代码。

JAVA提供了不同寻常方式的锁：每个JAVA对象都可以作为一个锁。即逻辑上有个关联锁，而不是提供一个显式的lock()和unlock()函数。JAVA提供了同步块来获得和释放锁。在指定的代码块被执行期间一直保持住锁。

synchronized (object_used_as_lock) {
   <i>code to be executed with lock held</i>
 }

尽管最近JAVA版本提供了显式锁操作(java.util.concurent.locks)，同步锁有实质性的好处，锁可以沿着代码块的方向释放，其中包括异常被抛出，从而消除错误的常见来源。

正如我们上面提及的，同步变量或者更正确的对象字段，通常用volatile关键字声明。由于不是一个单独的类型，可能有些令人惊讶，结果是：

数组元素不能同步，因为没有办法吧数组元素声明为volatile。

正如我们前面暗示的，volatile仅仅影响个别的内存存储，如果i被声明为volatile int i,那么++i包含两个单独的不可分割的内存访问，即增量作为一个不可分割的整体。

Java.util.concurrent.atomic包提供了一些原子类型规避这两种结果。

Java.util.concurrent提供了许多其他的措施支持多线程，包括丰富的类库用来同步或线程间的交互。

一些C++0x 特征

约定成俗，我们要用术语c++0x指下一个c++标准，尽管我们并不期望它被正式作为一个ISO标准直到2010或2011年。一个委员会起草的标准目前是可用的，并且我们期望许多供应商支持早于2011年的部分，在这我们所有的解释明确地适应2008委员会草案。

和当前(2003)C++标准不同，C++0X明确的支持线程，线程通过std::thread类的实例创建，调用构造函数或者执行可调用的对象。

由于C++没有被设计来提供保护不受信任的代码的，它无法保证数据争用，允许数据争用的任意程序产生”未定义行为”。

数据争用比较少的时候，提供的一些低层次的类库措施不能用来提供连续一致性。正像JAVA，这显而易见不是官方语言描述，在这种情况下，不使用数据争用而用低层次类库措施的语言描述更为复杂。

可以通过构造互斥获得锁，典型的是std::mutex，然后通过它获得构造函数std::lock_quard对象，确保在lock_quard析构函数释放锁，正如JAVA中被释放，即使是抛出异常。因此看起来像典型的代码来获得一个锁。

#include <mutex>
std::mutex mtx; // The lock; shared by multiple threads
…
{std::lock_guard _(mtx);
  ++c;
}

在c++0x中，整形同步变量i可能被声明为atomic<int> i;

同步变量与普通变量不同有个不同的类型，因此可以提供成员函数的不同实现，如果i像以上一样被声明，并发访问确保了正如以前一样的连续一致的行为，但是也确保了一个不可分割的操作，++i自动增加。

（C++里也有Volatile，由于历史原因，这意味着别的。）

目前看来，c++0x模型将在其他环境中，目前迹象表明，下一个C标准将遵循一种方法类似c++0x。OpenMP似乎也正走向一个类似解决方案。