注册 登录  
 加关注
   显示下一条  |  关闭
温馨提示!由于新浪微博认证机制调整,您的新浪微博帐号绑定已过期,请重新绑定!立即重新绑定新浪微博》  |  关闭

gmd20的个人空间

// 编程和生活

 
 
 

日志

 
 

?线上的freeDiameter碰到一个比较古老的glibc版本里面一个条件变量收不到信号的bug  

2013-11-18 15:02:04|  分类: linux相关 |  标签: |举报 |字号 订阅

  下载LOFTER 我的照片书  |

?现象就是,一个线程pthread_cond_wait 在一个条件变量上面,然后pthread_cancel 取消这线程。

然后一个新的线程又pthread_cond_wait  在这同一个条件变量上面。 接下来其他线程对pthread_cond_signal操作,就不能唤醒这个第二个pthread_cond_wait 的线程了。后面信号都收不到了。

暂时有个workaround是可以用pthread_cond_broadcast取代pthread_cond_signal来发送信号,那么就可以唤醒第二个线程。但这个有惊群问题的,如果等待的线程比较多的话。在redhat 3的2.3.2的glibc有这个问题。

后来在网上碰巧搜索到这个是glibc的bug:


https://sourceware.org/bugzilla/show_bug.cgi?id=3123

One thread blocks in pthread_cond_wait, another thread signals the condition 

variable and immediatley afterwards cancels the first thread.
A new thread blocking on the same condition variable can't be woken up with 
pthread_cond_signal.

remark: pthread_cond_timedwait shows the same behaviour

workaround: if pthread_cond_broadcast is used instead of pthread_cond_signal, 
it works

The attached testcase is a try to make a minimal example, the situation 
occurred in a large C++ project.
In this project there are three threads with different realtime priorities 
involved (one waites, one signals and one cancels).




在网上可以找到这个bug 相关的历史更新记录,和修改


2006-09-12  Kaz Kojima  <kkojima@rr.iij4u.or.jp>

	* sysdeps/unix/sysv/linux/sh/pthread_cond_broadcast.S: For PI
	mutexes wake all mutexes.
	* sysdeps/unix/sysv/linux/sh/pthread_cond_wait.S: Don't increment
	WAKEUP_SEQ if this would increase the value beyond TOTAL_SEQ.
	* sysdeps/unix/sysv/linux/sh/pthread_cond_timedwait.S: Likewise.

2006-09-12  Ulrich Drepper  <drepper@redhat.com>

	* tst-cond22.c (tf): Slight changes to the pthread_cond_wait use
	to guarantee the thread is always canceled.

2006-09-08  Jakub Jelinek  <jakub@redhat.com>

	* tst-cond22.c: Include pthread.h instead of pthreadP.h.
	Include stdlib.h.
	* sysdeps/pthread/pthread_cond_wait.c (__condvar_cleanup): Only
	increase FUTEX if increasing WAKEUP_SEQ.  Fix comment typo.
	* sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S: Likewise.
	* sysdeps/unix/sysv/linux/i386/i486/pthread_cond_timedwait.S: Likewise.
	* sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: Likewise.

2006-09-08  Ulrich Drepper  <drepper@redhat.com>

	[BZ #3123]
	* sysdeps/pthread/pthread_cond_wait.c (__condvar_cleanup): Don't
	increment WAKEUP_SEQ if this would increase the value beyond TOTAL_SEQ.
	* sysdeps/unix/sysv/linux/i386/i486/pthread_cond_wait.S: Likewise.
	* sysdeps/unix/sysv/linux/i386/i486/pthread_cond_timedwait.S: Likewise.
	* sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S: Likewise.
	* Makefile (tests): Add tst-cond22.
	* tst-cond22.c: New file.




https://github.com/lattera/glibc/commit/346e6ad4016f3a19f71ccd0edd8a2682746d6fe7

https://github.com/lattera/glibc/commit/0ecb606cb6cf65de1d9fc8a919bceb4be476c602


https://chromium.googlesource.com/chromiumos/third_party/glibc/+/glibc-2.16.0


https://chromium.googlesource.com/chromiumos/third_party/glibc/+/4dc13104d1921123bd6475fb84d5aadfa9959f8c/nptl/ChangeLog


可以找到glibc的源码,自己把这个修复的代码合并进去,编译个新的glibc出来吧。

  评论这张
 
阅读(470)| 评论(0)
推荐 转载

历史上的今天

评论

<#--最新日志,群博日志--> <#--推荐日志--> <#--引用记录--> <#--博主推荐--> <#--随机阅读--> <#--首页推荐--> <#--历史上的今天--> <#--被推荐日志--> <#--上一篇,下一篇--> <#-- 热度 --> <#-- 网易新闻广告 --> <#--右边模块结构--> <#--评论模块结构--> <#--引用模块结构--> <#--博主发起的投票-->
 
 
 
 
 
 
 
 
 
 
 
 
 
 

页脚

网易公司版权所有 ©1997-2017