Chinaunix首页 | 论坛 | 博客
  • 博客访问: 993323
  • 博文数量: 200
  • 博客积分: 5011
  • 博客等级: 大校
  • 技术积分: 2479
  • 用 户 组: 普通用户
  • 注册时间: 2008-06-27 15:07
文章分类

全部博文(200)

文章存档

2009年(12)

2008年(190)

我的朋友

分类:

2008-12-09 19:00:11

Chapter 11 exercises

Which sequence of steps is correct?

  1. Lock a mutex (pthread_mutex_lock).
  2. Change the condition protected by the mutex.
  3. Signal threads waiting on the condition (pthread_cond_broadcast).
  4. Unlock the mutex (pthread_mutex_unlock).

or

  1. Lock a mutex (pthread_mutex_lock).
  2. Change the condition protected by the mutex.
  3. Unlock the mutex (pthread_mutex_unlock).
  4. Signal threads waiting on the condition (pthread_cond_broadcast).

答案:这两个实现都正确,取决于不同的环境,各有优缺点:

第一个,在我们发送signal的时候,我们还持有mutex,这样被唤醒的thread在从wait中醒来的时候会尝试去给mutex加锁(这是pthread_cond_wait的定义),但是他们不可能获得锁,因为所还没有释放,因此他们又进入了加锁睡眠。等我们释放掉锁之后他们才继续执行。所以说,有点浪费CPU

第二个,在我们发送signal之前,就已经将锁释放了,当然现在外部的条件已经变化了,只不过我们还没有去通知某人去处理它。但由于此时的锁已经释放了,所以有可能在我们发送signal之前,由另一个人跑过来加了锁,然后将资源处理了,然后放开了锁跑掉了(或者还没有放开锁)。此时,我们再次调用signal去通知原本要通知的人,于是该人醒来,就尝试去加锁,如果中间哪个人已经将锁释放掉了,那么加锁成功,取处理资源,却发现资源已被中间哪个人处理掉了。所以没事干了,放掉锁,休息去吧。所以,当我们从睡梦中醒来的时候,一定要重新检查条件是否满足,如果不满足,就不要做什么。因为在我们睡眠的过程中,我们没有锁,所以不知道外界发生了什么。

当然,如果中间哪个人并没有及时将锁释放,等原本要通知的人被唤醒的时候,尝试加锁,也是加不上的,他就依然会block,直到中间哪个家伙处理完事情,放掉锁。接下来同上面一样了就。

 

阅读(728) | 评论(0) | 转发(0) |
给主人留下些什么吧!~~