多线程通信的注意问题

1.主线程和子线程通过局部变量传递消息时

在主线程和子线程之间传递参数时，为了避免竞争引发的问题，经常使用动态申请的内存，各个线程使用各自的内存在主线程和子线程之间通信时。这样做的原因就是防止父子线程竞争带来的问题。

以下是实例：

2.条件变量相关的问题（转）

pthread_mutex_lock();  
while(condition_is_false)  
    pthread_cond_wait();  
pthread_mutex_unlock(); 

为什么在pthread_cond_wait()前要加一个while循环来判断条件是否为假呢？

APUE中写道:
传递给pthread_cond_wait的互斥量对条件进行保护，调用者把锁住的互斥量传给函数。函数把调用线程放到等待条件的线程列表上，然后对互斥量解锁，这两个操作是原子操作。
线程释放互斥量，等待其他线程发给该条件变量的信号（唤醒一个等待者）或广播该条件变量（唤醒所有等待者）。当等待条件变量时，互斥量必须始终为释放的，这样其他线程才有机会锁住互斥量，修改条件变量。当线程从条件变量等待中醒来时，它重新继续锁住互斥量，对临界资源进行处理。
条件变量的作用是发信号，而不是互斥。其仅仅是起到了一个通知的作用。。即使在没有线程等待的时候pthread_cond_signal也不会产生错误，
wait前检查
对于多线程程序，不能够用常规串行的思路来思考它们，因为它们是完全异步的，会出现很多临界情况。比如：pthread_cond_signal的时间早于pthread_cond_wait的时间，这样pthread_cond_wait就会一直等下去，漏掉了之前的条件变化。

对于这种情况，解决的方法是在锁住互斥量之后和等待条件变量之前，检查条件变量是否已经发生变化。

if(condition_is_false)  
    pthread_cond_wait(); 

这样在等待条件变量前检查一下条件变量的值，如果条件变量已经发生了变化，那么就没有必要进行等待了，可以直接进行处理。这种方法在并发系统中比较常见，例如之前PACKET_MMAP中poll的竞争条件的解决方法。
-----------------------------------------------------------------------
忽然想起了设计模式中的单件模式的"双重检查加锁"：

[cpp]  view plain copy

1. Singleton *getInstance()  
2. {  
3.     if(ptr==NULL)  
4.     {  
5.         LOCK();  
6.         if(ptr==NULL)  
7.         {  
8.             ptr = new Singleton();  
9.         }  
10.         UNLOCK();  
11.     }  
12.     return ptr;  
13. }  

这样只有在第一次的时候会进行锁(应该是第一轮，如果刚开始有多个线程进入了最上层的ptr==NULL代码块，就会有多次加锁，但是只有第一个进去的线程会进行new Singleton，之后的仅仅是加锁解锁而已)。
pthread_once()的实现也是基于单件模式的。
pthread_once函数首先检查控制变量，以判断是否已经完成初始化。如果完成，pthread_once简单的返回；否则，pthread_once调用初始化函数(没有参数)，并记录下初始化被完成。如果在一个线程初始化时，另外的线程调用pthread_once，则调用线程将等待，直到那个线程完成初始化后返回。换句话，当调用pthread_once成功返回时，调用者能够肯定所有的状态已经初始化完毕。

[cpp]  view plain copy

1. int  
2. __pthread_once (once_control, init_routine)  
3.      pthread_once_t *once_control;  
4.      void (*init_routine) (void);  
5. {  
6.   /* XXX Depending on whether the LOCK_IN_ONCE_T is defined use a 
7.      global lock variable or one which is part of the pthread_once_t 
8.      object.  */  
9.   if (*once_control == PTHREAD_ONCE_INIT)  
10.     {  
11.       lll_lock (once_lock, LLL_PRIVATE);  
12.       /* XXX This implementation is not complete.  It doesn't take 
13. cancelation and fork into account.  */  
14.       if (*once_control == PTHREAD_ONCE_INIT)  
15. {  
16.   init_routine ();  
17.   *once_control = !PTHREAD_ONCE_INIT;  
18. }  
19.       lll_unlock (once_lock, LLL_PRIVATE);  
20.     }  
21.   return 0;  
22. }  

-----------------------------------------------------------------------
pthread_cond_wait中的while()不仅仅在等待条件变量前检查条件变量，实际上在等待条件变量后也检查条件变量。pthread_cond_wait返回后，还需要检查条件变量，这是为什么呢？难道pthread_cond_wait不是pthread_cond_signal触发了某个condition导致的吗？这里有两种情况，一种是假唤醒，另一种是广播唤醒。
这个地方有些迷惑人，实际上pthread_cond_wait的返回不仅仅是pthread_cond_signal和pthread_cond_broadcast导致的，还会有一些假唤醒，也就是spurious wakeup。
何为假唤醒？顾名思义就是虚假的唤醒，与pthread_cond_signal和pthread_cond_broadcast的唤醒相对。那么什么情况下会导致假唤醒呢？可以阅读参考1。
signal
大致意思是：
在linux中，pthread_cond_wait底层是futex系统调用。在linux中，任何慢速的阻塞的系统调用当接收到信号的时候，就会返回-1，并且设置errno为EINTR。在系统调用返回前，用户程序注册的信号处理函数会被调用处理。
注:什么有样的系统调用会出现接收信号后发挥EINTR呢？
慢速阻塞的系统调用，有可能会永远阻塞下去的那种。当接收到信号的时候，认为是一个返回并执行其他代码的一个时机。
信号的处理也不简单，因为有些慢系统调用被信号中断后是会自动重启的，所以我们通常需要用siginterrupt(signo, 1)来关闭重启或者在用sigaction安装信号处理函数的时候取消SA_RESTART标志，之后就可以通过判断信号的返回值是否是-1和errno是否为EINTR来判断是否有信号抵达
如果关闭了SA_RESTART的一些使用慢速系统调用的应用，一般都采用while()循环，检测到EINTR后就重新调用。

[cpp]  view plain copy

1. while(1)  
2. {  
3.    int ret = syscall();  
4.    if(ret<0 && errno==EINTR)  
5.        continue;  
6.    else  
7.        break;  
8. }  

但是，对于futex这种方法不行，因为futex结束后，再重新运行的过程中，会出现一个时间窗口，其他线程可能会在这个时间窗口中进行pthread_cond_signal，这样，再进行pthread_cond_wait的时候就丢失了一次条件变量的变化。解决方法就是在pthread_cond_wait前检查条件变量，也就是

[cpp]  view plain copy

1. pthread_mutex_lock();  
2. while(condition_is_false)  
3.     pthread_cond_wait();  
4. pthread_mutex_unlock();  

pthread_cond_broadcast
实际上，不仅仅信号会导致假唤醒，pthread_cond_broadcast也会导致假唤醒。加入条件变量上有多个线程在等待，pthread_cond_broadcast会唤醒所有的等待线程，而pthread_cond_signal只会唤醒其中一个等待线程。这样，pthread_cond_broadcast的情况也许要在pthread_cond_wait前使用while循环来检查条件变量。
参考：
http://vladimir_prus.blogspot.com/2005/07/spurious-wakeups.html
http://www.lambdacs.com/cpt/FAQ.html#Q94
http://groups.google.de/group/comp.programming.threads/msg/bb8299804652fdd7
http://www.win.tue.nl/~aeb/linux/lk/lk-4.html#ss4.5
http://blog.chinaunix.net/u/5251/showart_309061.html