线程同步——条件变量.docVIP

1.互斥量的存在问题： ??? 互斥量是线程程序必需的工具，但它们并非万能的。例如，如果线程正在等待共享数据内某个条件出现，那会发生什么呢？它可以重复对互斥对象锁定和解锁，每次都会检查共享数据结构，以查找某个值。但这是在浪费时间和资源，而且这种繁忙查询的效率非常低。 ??? 在每次检查之间，可以让调用线程短暂地进入睡眠，比如睡眠三秒钟，但是因此线程代码就无法最快作出响应。真正需要的是这样一种方法：当线程在等待满足某些条件时使线程进入睡眠状态。一旦条件满足，就唤醒因等待满足特定条件而睡眠的线程。如果能够做到这一点，线程代码将是非常高效的，并且不会占用宝贵的互斥对象锁。这正是 POSIX 条件变量能做的事！ ? 2.条件变量: ??? 条件变量通过允许线程阻塞和等待另一个线程发送信号的方法弥补了互斥锁的不足，它常和互斥锁一起使用。使用时，条件变量被用来阻塞一个线程，当条件不满足时，线程往往解开相应的互斥锁并等待条件发生变化。一旦其它的某个线程改变了条件变量，它将通知相应的条件变量唤醒一个或多个正被此条件变量阻塞的线程。这些线程将重新锁定互斥锁并重新测试条件是否满足。 ? 3.条件变量的相关函数 （1）创建和注销 ??? 条件变量和互斥锁一样，都有静态动态两种创建方式 a.静态方式 ??? 静态方式使用PTHREAD_COND_INITIALIZER常量，如下：??? pthread_cond_t cond=PTHREAD_COND_INITIALIZER ? b.动态方式??? int pthread_cond_init(pthread_cond_t *cond, pthread_condattr_t *cond_attr) ??? 使用 cond_attr 指定的属性初始化条件变量 cond，当 cond_attr 为 NULL 时，使用缺省的属性。LinuxThreads 实现条件变量不支持属性，因此 cond_attr 参数实际被忽略。 c.注销 ??? int pthread_cond_destroy(pthread_cond_t *cond) ??? 注销一个条件变量需要调用pthread_cond_destroy()，只有在没有线程在该条件变量上等待的时候才能注销这个条件变量，否则返回EBUSY。因为Linux实现的条件变量没有分配什么资源，所以注销动作只包括检查是否有等待线程。 ? （2）等待和激发 a.等待 ??? int pthread_cond_wait(pthread_cond_t *cond, pthread_mutex_t *mutex)??? 了解 pthread_cond_wait() 的作用非常重要——它是 POSIX 线程信号发送系统的核心，也是最难以理解的部分。 ??? 首先，让我们考虑以下情况：线程为查看已链接列表而锁定了互斥对象，然而该列表恰巧是空的。这一特定线程什么也干不了——其设计意图是从列表中除去节点，但是现在却没有节点。因此，它只能： ??? 锁定互斥对象时，线程将调用 pthread_cond_wait(mycond,mymutex)。pthread_cond_wait() 调用相当复杂，因此我们每次只执行它的一个操作。 ??? pthread_cond_wait() 所做的第一件事就是同时对互斥对象解锁（于是其它线程可以修改已链接列表），并等待条件 mycond 发生（这样当 pthread_cond_wait() 接收到另一个线程的“信号”时，它将苏醒）。现在互斥对象已被解锁，其它线程可以访问和修改已链接列表，可能还会添加项。 ??? 此时，pthread_cond_wait() 调用还未返回。对互斥对象解锁会立即发生，但等待条件 mycond 通常是一个阻塞操作，这意味着线程将睡眠，在它苏醒之前不会消耗 CPU 周期。这正是我们期待发生的情况。线程将一直睡眠，直到特定条件发生，在这期间不会发生任何浪费 CPU 时间的繁忙查询。从线程的角度来看，它只是在等待 pthread_cond_wait() 调用返回。 ??? 现在继续说明，假设另一个线程（称作“2 号线程”）锁定了 mymutex 并对已链接列表添加了一项。在对互斥对象解锁之后，2 号线程会立即调用函数 pthread_cond_broadcast(mycond)。此操作之后，2 号线程将使所有等待 mycond 条件变量的线程立即苏醒。这意味着第一个线程（仍处于 pthread_cond_wait() 调用中）现在将苏醒。 ??? 现在，看一下第一个线程发生了什么。您可能会认为在2号线程调用 pthread_cond_broadcast(mymutex) 之后，1 号线程的 pthread_cond_wait