设为首页 加入收藏

TOP

10.4.1 synchronized
2013-10-07 15:05:27 来源: 作者: 【 】 浏览:77
Tags:10.4.1 synchronized

10.4  多线程扩展

既然我们已经讨论了与多线程有关的一系列议题,你现在大概已经开始认同语言对多线程操作提供内建支持是很有用的。事实上,有几门语言确实提供了多线程构造。C++(www.cppentry.com)的传统则是偏好提供新的库设施而非新语言元素。我们接下来考察一些领域,看看这些领域如何提供语言级别的多线程支持,以及我们如何使用库(外加一点预处理技巧)进行实现。

10.4.1  synchronized

D和Java中都有synchronized关键字,它可以被用于守护临界区,像这样:

  1. Object obj = new Object();  
  2. . . .  
  3. synchronized(obj)  
  4. {  
  5.   . . . // 临界区代码  
  6. }  

将synchronized关键字合并到语言中的途径之一,是将如上的代码自动转换为下面的这种形式:
  1. { __lock_scope__<Object> __lock__(obj);  
  2. {  
  3.   . . . // 临界区代码  
  4. }  
  5. }  

__lock_scope__从任何意义上说都跟6.2节的lock_scope模板类似。这实现起来相当简单,并且,使用一个关联的std::lock_traits模板,可以令任何"可trait"类型的实例通过这种方式进行同步,而并不一定要将它们转换成同步对象锁。

然而,这个理由还不足以说明语言扩展的必要性,因为通过一点点宏我们就可以实现同样的效果。基本上,我们所需要的仅仅是下面这两个宏:

  1. #define SYNCHRONIZED_BEGIN(T, v) \  
  2.   {                              \  
  3.   lock_scope<T> __lock__(v);  
  4. #define SYNCHRONIZED_END() \  
  5.   }  

这种做法只有一个小小的遗憾,那就是对象的类型不能被自动推导出来,我们必须手工给出,而且代码看起来有点不够优美:
  1. SYNCHRONIZED_BEGIN(Object, obj)  
  2. {  
  3.   . . . // 临界区代码  
  4. }  
  5. SYNCHRONIZED_END()  

如果你不喜欢SYNCHRONIZED_END()部分,你可以耍一点小技巧,这样来定义SYNCHRONIZED()宏:
  1. #define SYNCHRONIZED(T, v)                            \  
  2.   for(synchronized_lock<lock_scope<T> > __lock__(v);   \  
  3.       __lock__; __lock__.end_loop())  

类模板synchronized_lock<>在这里只是用于定义一个状态,2并结束这个for循环,因为我们不能在这个for循环内声明第二个条件变量(见17.3节)。这是一个螺栓(bolt-in)类(见第22章),大致如下:

程序清单10.5

  1. template <typename T> 
  2. struct synchronized_lock  
  3.   : public T  
  4. {  
  5. public:  
  6.   template <typename U> 
  7.   synchronized_lock(U &u)  
  8.     : T(u)  
  9.     , m_bEnded(false)  
  10.   {}  
  11.   operator bool () const  
  12.   {  
  13.     return !m_bEnded;  
  14.   }  
  15.   void end_loop()  
  16.   {  
  17.     m_bEnded = true;  
  18.   }  
  19. private:  
  20.   bool  m_bEnded;  
  21. };  

这里还有另一个问题(当然了!)。正如17.3节描述的,编译器对for循环的声明具有不同的反应。如果同一个作用域中出现了两个同步区段,那么有些老式的编译器就会发出抱怨。
  1. SYNCHRONIZED(Object, obj)  
  2. {  
  3.   . . . // 临界区代码  
  4. }  
  5.   . . . // 非临界区代码  
  6. SYNCHRONIZED(Object, obj) // 错误:“重新定义__lock__”  
  7. {  
  8.   . . . // 其他临界区代码  
  9. }  

因此,一个可移植的解决方案必须确保每个"__lock__"都是不一样的,为此我们不得不面对"肮脏的"预处理代码:
  1. #define concat__(x, y)            x ## y  
  2. #define concat_(x, y)             concat__(x, y)  
  3. #define SYNCHRONIZED(T, v)                       \  
  4.   for(synchronized_lock<lock_scope<T> >        \  
  5.       concat_(__lock__, __LINE__) (v);          \  
  6.       concat_(__lock__, __LINE__);             \  
  7.       concat_(__lock__, __LINE__)  .end_loop())  

很丑陋,不是吗?但这种方案在我测试过的所有编译器上都能工作。如果你不需要考虑有关for循环的历史遗留错误,你可以使用原先那个更简洁的版本。随书光盘中包含了这些宏和类的完整版本。
】【打印繁体】【投稿】【收藏】 【推荐】【举报】【评论】 【关闭】 【返回顶部
分享到: 
上一篇10.2.2 自旋互斥体 下一篇10.3.3 性能比较

评论

帐  号: 密码: (新用户注册)
验 证 码:
表  情:
内  容: