boost 线程、互斥体、条件变量

来源:互联网 发布:手机处方软件 编辑:程序博客网 时间:2024/05/18 03:09

boost 线程、互斥体、条件变量

1、任何技术都是针对特定场景设计的,也就是说,为了解决某个问题而设计的。

2、考虑下面一种场景:一个小旅馆,只有一个卫生间,有清洁人员,店主人,和旅客。卫生间用完之后,就会自动锁闭,必须取钥匙,才能进入卫生间。

3、在上面的场景中,卫生间是共享资源,清洁人员和旅客使用卫生间的过程,就是两个线程,钥匙是互斥体。

4、假定卫生间只有一个坑,一次只能一个人使用,因此就只有一个钥匙。谁要使用卫生间,必须拿到钥匙。别人拿到钥匙,自己必须等待,拿钥匙就是,程序中lock互斥体。

5、通过钥匙保证了,卫生间一次只能一个人使用。这样的好处是:通过一个小钥匙,控制了一大块资源的使用。

6、钥匙保证了,不同人之间不能同时使用卫生间。考虑下面的场景:旅客甲拿到了钥匙,但钥匙暂时忘记放哪了,因此,向店主人再要一把钥匙,这个时候会发生什么?

  a、假设店主人不给,就会造成死锁,大家谁也用不上卫生间了。大家要想用卫生间,就必须等待甲把钥匙还了,可现在甲还不了。

  b、店主人思考了,刚才钥匙给甲用了,甲把钥匙丢了。我不能把备用钥匙给别人,不然,甲找到钥匙,就可能和别人一起用钥匙了。但是,我可能把备用钥匙给甲,不会造成多个人同时用卫生间。这就是递归互斥体,允许一个人多次拿到钥匙,但是不允许多个人同时拿到钥匙。

7、考虑下面的场景:清洁人员打少卫生间,旅客使用卫生间,一个旅客使用后,必须等清洁人员打扫完毕,下一个旅客才能使用。正常情况下:清洁人员打扫之前,先看一下卫生间是不是脏的,如果脏的话,才去拿钥匙准备打扫。旅客使用卫生间之前,先看一下,卫生间是不是干净的,如果干净的话,才去拿钥匙,准备使用卫生间。有一次,旅客甲很急,不管卫生间是否干净,就拿了钥匙,这时候出现问题了:卫生间是脏的,旅客甲没法使用。另一方面,清洁人员,也没法打扫,因为钥匙在甲那里。这样就死锁了。怎么办?

8、问题的根源是:旅客甲没检查卫生间是否可用,就把钥匙拿过来了,结果呢,钥匙拿来了,卫生间不能用。解决办法是:旅客甲主动把钥匙给清洁人员,并告诉清洁人员,打扫好了,再把钥匙给我,我再用卫生间。这就是条件变量,使用者发现,共享资源不能用,主动把钥匙交出来,等待别人把共享资源弄好,把钥匙还回来,然后再使用。

分类: C++




boost 互斥体和锁

 1、共享资源是一个自动锁住的房间,互斥体是钥匙,进入房间必须取钥匙,离开房间应该还钥匙。这就对应着互斥体的lock(取钥匙)和unlock(还钥匙)。 

2、考虑下面的场景:还钥匙的时候出现异常,会发生什么? 

  导致死锁,因为钥匙归还失败,所有人都没法再取到钥匙。 

3、如何解决这个问题? 

  想一下,动态分配内存存在类似的情况。如果忘记delete,会导致内存泄漏。它是如何解决的? 在栈上分配对象,要一个特点,那就是离开作用域后,对象肯定要调用析构方法。利用这个特点,可以使用对象对指针封装,在对象的析构方法中进行delete,就保证了一定会执行delete。这就是智能指针。因为智能指针,不是针对一个特定类型的指针,因此把智能指针设计为类的模版,根据模版实参特例化一个模板类。

  同样道理,也可以使用相同技术,对互斥体封装。这就是 lock类模版。在lock的构造方法调用互斥体的lock方法,在lock的析构方法调用互斥体的unlock方法。 

4、mutex是对象类,lock是模板类。 

5、常用的互斥体有: 

  boost::mutex 

  boost::timed_mutex 

  boost::shared_mutex 

  boost::recursive_mutex 

6、lock的类模版有: 

  boost::unique_lock<T> 

  boost::shared_lock<T> 

  对类模版特例化,可以生成不同的lock类。


0 0
原创粉丝点击