标签：des style color strong width io
编译：
[X61@horizon threads]$ gcc thread_cond.c -lpthread -o tcd
以下是程序运行结果：
[X61@horizon threads]$ ./tcd
thread1: lock 30
thread1: unlock 40
thread2: lock 52
thread2: wait 1 55
thread1: lock 30
thread1: unlock 40
thread1: lock 30
thread1:signal 1 33
thread1:signal 2 35
thread1: unlock 40
thread2: wait 2 57
thread2: unlock 61
thread1: lock 30
thread1: unlock 40
thread2: lock 52
thread2: wait 1 55
thread1: lock 30
thread1: unlock 40
thread1: lock 30
thread1:signal 1 33
thread1:signal 2 35
thread1: unlock 40
thread2: wait 2 57
thread2: unlock 61
这里的两个关键函数就在pthread_cond_wait和pthread_cond_signal函数。
本例中：
线程一先执行，获得mutex锁，打印，然后释放mutex锁，然后阻塞自己1秒。
线程二此时和线程一应该是并发的执行 ，这里是一个要点，为什么说是线程此时是并发的执行，因为此时不做任何干涉的话，是没有办法确定是线程一先获得执行还是线程二先获得执行，到底那个线程先获得执行，取决于操作系统的调度，想刻意的让线程2先执行，可以让线程2一出来，先sleep一秒。
这里并发执行的情况是，线程一先进入循环，然后获得锁，此时估计线程二执行,阻塞在
pthread_mutex_lock(&mutex);
这行语句中，直到线程1释放mutex锁
pthread_mutex_unlock(&mutex);/*解锁互斥量*/
然后线程二得已执行，获取metux锁，满足if条件，到pthread_cond_wait (&cond,&mutex);/*等待*/
这里的线程二阻塞，不仅仅是等待cond变量发生改变，同时释放mutex锁
（这里wait的时候会释放mutex，而一旦接收到信号（且其它线程解锁mutex）退出的时候会重新给mutex加锁，实际上，线程信号与线程锁依赖，详见下篇）
mutex锁释放后，线程1终于获得了mutex锁，得已继续运行，当线程1的if（i%3==0）的条件满足后，通过pthread_cond_signal发送信号，告诉等待cond的变量的线程（这个情景中是线程二），cond条件变量已经发生了改变。
不过此时线程二并没有立即得到运行 ，因为线程二还在等待mutex锁的释放，所以线程一继续往下走，直到线程一释放mutex锁，线程二才能停止等待，打印语句，然后往下走通过pthread_mutex_unlock(&mutex)释放mutex锁，进入下一个循环。
pthread_count_t与pthread_mutex_t的运用,布布扣,bubuko.com
pthread_count_t与pthread_mutex_t的运用
标签：des style color strong width io
原文地址：http://blog.csdn.net/jiangheng0535/article/details/37907209
