线程基础之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似乎也正走向一个类似解决方案。

原创文章,转载请注明: 转载自并发编程网 – ifeve.com本文链接地址: 线程基础之JAVA和C++0x的特性



iamyzs

衣卓时 JAVA software engineer

Latest posts by iamyzs (see all)

FavoriteLoading添加本文到我的收藏
  • Trackback are closed
  • Comments (1)
  1. 有必要现在翻译一篇09年的文章么?

You must be logged in to post a comment.

return top