转载于:http://www.cnblogs.com/TianFang/archive/2006/12/04/581793.html

ACE Guard类属

与C一级的互斥体API相比较,Mutex包装为同步多线程控制提供了一种优雅的接口。但是,Mutex潜在地容易出错,因为程序员有可能忘记调用release方法(当然,C级的互斥体API更容易出错)。这可能由于程序员的疏忽或是C++异常的发生而发生,然而,其导致及其严重的后果--死锁。

因此,为改善应用的健壮性,ACE同步机制有效地利用C++类构造器和析构器的语义来确保Mutex锁被自动获取和释放。

ACE提供了一个称为Guard、Write_Guard和Read_Guard的类族,确保在进入和退出C++代码块时分别自动获取和释放锁。

Guard类是最基本的守卫机制,定义可以简化如下(实际定义比这相对要复杂而完善一点):

template <class LOCK>
class Guard
{
public:
    Guard (LOCK &l): lock_ (&l){ lock_.acquire (); }

˜Guard (void) {    lock_.release (); }
private:
    LOCK lock_;
}

Guard类的对象定义一"块"代码,在其上锁被自动获取,并在退出块时自动释放,即使是程序抛异常也能保证自动解锁。这种机制也能为Mutex、RW_Mutex和Semaphore同步封装工作。

对于读写锁,由于加锁接口不一样,ace也提供了相应的Read_Guard和Write_Guard类,Read_Guard和Write_Guard类有着与Guard类相同的接口。但是,它们的acquire方法分别对锁进行读和写。

缺省地, Guard类构造器将会阻塞程序,直到锁被获取。会有这样的情况,程序必须使用非阻塞的acquire调用(例如,防止死锁)。因此,可以传给ACE Guard的构造器第二个参数(请参看原始代码,而不是我这里的简化代码),指示它使用锁的try_acquire方法,而不是acquire。随后调用者可以使用Guard的locked方法来原子地测试实际上锁是否已被获取。

用Guard重写上一节的Thread1方法如下(注释了的部分是原有代码):

void* Thread1(void *arg) 
{
    ACE_Guard<ACE_Thread_Mutex> guard(mutex);
    //mutex.acquire();
    ACE_OS::sleep(3);
    cout<<endl<<"hello thread1"<<endl;
    //mutex.release();

return NULL; 
}

相比较而言,使用Guard更加简洁,并且会自动解锁,免除了一部分后顾之忧。

注意:

  1. Guard只能帮你自动加解锁,并不能解决死锁问题,特别是对于那些非递归的互斥体来说使用Guard尤其要注意防止死锁。

Guard是在Guard变量析构时解锁,如果在同一函数中两次对同一互斥体变量使用Guard要注意其对象生命周期,否则容易造成死锁。

ACE线程管理机制-并发控制(2)的更多相关文章

  1. ACE线程管理机制-并发控制(3)

    转载于:http://www.cnblogs.com/TianFang/archive/2006/12/04/581854.html ACE Condition类属 ACE Condition类属(条 ...

  2. ACE线程管理机制-并发控制(1)

    转载于:http://www.cnblogs.com/TianFang/archive/2006/12/04/581771.html ACE Lock类属 锁类属包含的类包装简单的锁定机制,比如互斥体 ...

  3. ACE线程管理机制-并发控制(4)

    转载于:http://www.cnblogs.com/TianFang/archive/2006/12/04/581857.html ACE Synchronization类 这一类并发控制对象一般也 ...

  4. ACE线程管理机制-并发控制

    ACE有若干可用于并发控制的类.这些类可划分为以下范畴: ACE Lock类属 ACE Guard类属 ACE Condition类属 ACE Synchronization类 由于篇幅较长,我分别写 ...

  5. ACE线程管理机制-面向对象的线程类ACE_Task

    转载于:http://www.cnblogs.com/TianFang/archive/2006/12/05/583231.html 我们在前一章中使用ACE_Thread包装时,你一定已经注意到了一 ...

  6. ACE线程管理机制-线程的创建与管理

    转载于:http://www.cnblogs.com/TianFang/archive/2006/12/04/581369.html 有过在不同的操作系统下用c++进行过多线程编程的朋友对那些线程处理 ...

  7. [转载]Linux 线程实现机制分析

    本文转自http://www.ibm.com/developerworks/cn/linux/kernel/l-thread/ 支持原创.尊重原创,分享知识! 自从多线程编程的概念出现在 Linux ...

  8. Linux 线程实现机制分析 Linux 线程模型的比较:LinuxThreads 和 NPTL

    Linux 线程实现机制分析 Linux 线程实现机制分析  Linux 线程模型的比较:LinuxThreads 和 NPTL http://www.ibm.com/developerworks/c ...

  9. Linux 线程实现机制分析--转

    http://www.ibm.com/developerworks/cn/linux/kernel/l-thread/ 一.基础知识:线程和进程 按照教科书上的定义,进程是资源管理的最小单位,线程是程 ...

随机推荐

  1. Unity编辑器 - 编辑器控制特效播放

    编辑器控制特效播放 Unity的动画编辑器不能预览粒子系统的播放,为了方便预览特效,设想制作一个预览特效的工具,通常一个特效有三种组件: - Animation - Animator - Partic ...

  2. python学习笔记04 --------------基本运算符

    1.算数运算 + 加 - 减 * 乘 /   除 % 取模(先做除法,然后返回余数) ** 乘方(幂运算) //          取整(相除,然后返回商的整数部分) 2.比较运算(返回布尔值) == ...

  3. Struts2(九.利用layer组件实现图片显示功能)

    1.layer前端组件介绍 layer是一款口碑极佳的web弹层组件,她具备全方位的解决方案,致力于服务各个水平段的开发人员,您的页面会轻松地拥有丰富而友好的操作体验. http://sentsin. ...

  4. [Clr via C#读书笔记]Cp14字符字符串和文本处理

    Cp14字符字符串和文本处理 字符 System.Char结构,2个字节的Unicode,提供了大量的静态方法:可以直接强制转换成数值: 字符串 使用最频繁的类型:不可变:引用类型,在堆上分配,但是使 ...

  5. 机器学习(四)正则化与过拟合问题 Regularization / The Problem of Overfitting

    文章内容均来自斯坦福大学的Andrew Ng教授讲解的Machine Learning课程,本文是针对该课程的个人学习笔记,如有疏漏,请以原课程所讲述内容为准.感谢博主Rachel Zhang 的个人 ...

  6. truffle运行特殊 无法找到module的处理方法

    https://blog.csdn.net/SnWJy/article/details/80549227 错误描述: ​ truffle项目根目录执行truffle compile时,报错'modul ...

  7. canvas学习(三):文字渲染

    一.绘制基本的文字: var canvas = document.getElementById("myCanvas") var ctx = canvas.getContext('2 ...

  8. 自测之Lesson11:消息和消息队列

    题目:key及ftok函数的作用. 解答: key是用来创建消息队列的一个参数,当两个key相同时,创建消息队列会引起“误会”(除非有意为之).所以我们可以通过ftok函数来获得一个“不易重复”的ke ...

  9. 重构 之 总结代码的坏味道 Bad Smell (一) 重复代码 过长函数 过大的类 过长参数列 发散式变化 霰弹式修改

    膜拜下 Martin Fowler 大神 , 开始学习 圣经 重构-改善既有代码设计 . 代码的坏味道就意味着需要重构, 对代码的坏味道了然于心是重构的比要前提; . 作者 : 万境绝尘 转载请注明出 ...

  10. Java常用类之Math类

    Java 的常用类Math类: java.lang.Math 提供了系列的静态方法用于科学计算,其方法的参数和返回值类型一般为 double 类型. 如: 1. public static final ...