标签:技术 dict types get 成功 indent hal 环境 initial
在整理Java LockSupport.park()的东东。看到了个"Spurious wakeup"。又一次梳理下。
首先来个《UNIX环境高级编程》里的样例:
这个代码最easy让人搞混的是process_msg函数里的pthread_mutex_lock 和 pthread_mutex_unlock 是一对函数调用。前面加锁。后面解锁。的确,是加锁解锁。可是它们两不是一对的。它们的还有一半在pthread_cond_wait函数里。
pthread_cond_wait函数能够觉得它做了三件事:
mutex和condition实际上是绑定在一起的,一个condition仅仅能相应一个mutex。在Java的代码里,Condition对象仅仅能通过lock.newCondition()的函数来获取。
所谓的spurious wakeup。指的是一个线程调用pthread_cond_signal()。却有可能不止一个线程被唤醒。
为什么会出现这样的情况?wiki和其他的一些文档都仅仅是说在多核的情况下。简化实现同意出现这样的spurious wakeup。
。
在man文档里给出了一个可能的实现。然后解析为什么会出现。
假定有三个线程,线程A正在运行pthread_cond_wait,线程B正在运行pthread_cond_signal,线程C正准备运行pthread_cond_wait函数。
为什么pthread_cond_wait函数里一进入。就释放了mutex?没有找到什么解析。。
查看了glibc的源码,大概能够看出上面的一些影子,可是太复杂了,也没有搞明确为什么。。
/build/buildd/eglibc-2.19/nptl/pthread_cond_wait.c
/build/buildd/eglibc-2.19/nptl/pthread_cond_signal.c
只是从上面的解析,能够发现《UNIX高级编程》里的说明是错误的(可能是由于太久了)。
The caller passes it locked to the function, which then atomically places the calling thread on the list of threads waiting for the condition and unlocks the mutex.
上面的伪代码,一进入pthread_cond_wait函数就释放了mutex,明显和书里的不一样。
类似Java里ReentrantLock的非公平模式。
网上有些文章说。先singal再unlock,有可能会出现一种情况是被singal唤醒的线程会由于不能立即拿到mutex(还没被释放)。从而会再次休眠,这样影响了效率。从而会有一个叫“wait morphing”优化,就是假设线程被唤醒可是不能获取到mutex,则线程被转移(morphing)到mutex的等待队列里。
可是我查看了下glibc的源码,貌似没有发现有这样的“wait morphing”优化。
man文档里提到:
The pthread_cond_broadcast() or pthread_cond_signal() functions may be called by a thread whether or not it currently owns the mutex that threads calling pthread_cond_wait() or pthread_cond_timedwait() have associated with the condition variable during their waits; however, if predictable scheduling behavior is required, then that mutex shall be locked by the thread calling pthread_cond_broadcast() or pthread_cond_signal().
可见在调用singal之前。能够不持有mutex。除非是“predictable scheduling”,可预測的调度行为。这样的可能是实时系统才有这样的严格的要求。
而不用if来推断?
一个原因是spurious wakeup,但即使没有spurious wakeup。也是要用While来推断的。
比方线程A,线程B在pthread_cond_wait函数中等待,然后线程C把消息放到队列里,再调用pthread_cond_broadcast。然后线程A先获取到mutex。处理完消息完后,这时workq就变成NULL了。这时线程B才获取到mutex,那么这时实际上是没有资源供线程B使用的。所以从pthread_cond_wait函数返回之后,还是要推断条件是否成功。假设成立,再进行处理。
在这篇文章里,http://www.cppblog.com/Solstice/archive/2013/09/09/203094.html
给出的演示样例代码7里,觉得调用pthread_cond_broadcast来唤醒全部的线程是比較好的写法。可是我觉得pthread_cond_signal和pthread_cond_broadcast是两个不同东东,不能简单合并在同一个函数调用。
仅仅唤醒一个效率和唤醒全部等待线程的效率显然不能等同。典型的condition是用CLH或者MCS来实现的,要通知全部的线程,则要历遍链表,显然效率减少。另外。C++11里的condition_variable也提供了notify_one函数。
http://en.cppreference.com/w/cpp/thread/condition_variable/notify_one
这个在參考文档里没有说明。在网上找了些资料,也没有什么明白的答案。
我写了个代码測试。发现mutex是公平的。condition的測试结果也是差点儿相同。
http://en.wikipedia.org/wiki/Spurious_wakeup
http://siwind.iteye.com/blog/1469216
http://www.cppblog.com/Solstice/archive/2013/09/09/203094.html
http://www.cs.cmu.edu/afs/cs/academic/class/15492-f07/www/pthreads.html
4.锁--并行编程之条件变量(posix condition variables)
标签:技术 dict types get 成功 indent hal 环境 initial
原文地址:http://www.cnblogs.com/liguangsunls/p/6784579.html