We read every piece of feedback, and take your input very seriously.
To see all available qualifiers, see our documentation.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
commit 1e0d8ad让我想起了一个问题,当前mutex.h中的Mutex类在初始化pthread_mutex_t变量时,没有指定pthread_mutexattr_t属性,这将导致该互斥量的属性为PTHREAD_MUTEX_DEFAULT。而在linux下,这种属性的互斥量在 没有解锁时又重新加锁 下的行为是未定义的。是否有必要将互斥量改为非递归的?感觉这样会安全些。
The text was updated successfully, but these errors were encountered:
linux下,重复加锁是会死锁的,所以当前实现是可以工作的,我会再研究下其他几种类型,看哪个更适合替换。 关闭issue的原因是什么,你又有新的发现?
Sorry, something went wrong.
上午看错了,以为当前代码中有重复加锁的地方,但是居然没有死锁,现在排查清楚了,是看错了锁……
POSIX标准的手册中写的在PTHREAD_MUTEX_DEFAULT情况下,重复加锁会导致不确定行为,linux的一些版本中,PTHREAD_MUTEX_DEFAULT被映射到了PTHREAD_MUTEX_NORMAL,这样便会导致死锁。但这种映射是没有保证的。所以我感觉还是有必要替换一下的,至少应该改为PTHREAD_MUTEX_NORMAL。
已经移到baidu/common中了
No branches or pull requests
commit 1e0d8ad让我想起了一个问题,当前mutex.h中的Mutex类在初始化pthread_mutex_t变量时,没有指定pthread_mutexattr_t属性,这将导致该互斥量的属性为PTHREAD_MUTEX_DEFAULT。而在linux下,这种属性的互斥量在 没有解锁时又重新加锁 下的行为是未定义的。是否有必要将互斥量改为非递归的?感觉这样会安全些。
The text was updated successfully, but these errors were encountered: