Pthreads-锁定,2次解锁

Kev*_*ith 2 c c++ mutex locking pthreads

如果我理解正确,那么foo1()无法解锁&private_value_.因此,foo2()的thread_mutex_lock不起作用,因为foo1()从未释放它.

还有什么后果?

int main ( ... )

foo1();
foo2();

return 0;
}

foo1()
{
 pthread_mutex_lock(&private_value_);
 do something 
 // no unlock!
}

foo2()
{
 pthread_mutex_lock(&private_value_)
 do something
 pthread_mutex_unlock(&private_value_);
}
Run Code Online (Sandbox Code Playgroud)

Tyl*_*nry 5

程序应该如何编写以及当前编写的程序将如何表现之间似乎存在一些混淆.

此代码导致死锁,这并不表示互斥锁的工作方式有问题.它们正在按照它们的预期工作:如果您尝试重新获取已经锁定的非递归互斥锁,则代码将阻塞,直到互斥锁被解锁.这就是它应该如何运作.

由于此代码是单线程的,因此阻塞foo2将永远不会结束,因此您的程序将陷入僵局而不会进展.这很可能不是程序应该如何工作(因为它不是一个非常有用的程序).错误不在于互斥体的运行方式,而在于程序员如何选择使用它们.程序员应该在结束时拨打解锁电话foo1.

  • 不,你错了,这不一定会阻止.`如果互斥锁类型是PTHREAD_MUTEX_RECURSIVE,则互斥锁保持锁定计数的概念.当线程第一次成功获取互斥锁时,锁定计数设置为1.每次线程重新锁定此互斥锁时,锁定计数都会增加1.因此,如果使用设置了"PTHREAD_MUTEX_RECURSIVE"的属性进行初始化,则会隐藏此程序的错误并且行为看起来"正常". (3认同)
  • 我对此很清楚.您是否阅读过我写过"非递归互斥体"的部分?此外,OP对其观察到的行为的描述表明互斥锁在这种情况下不是递归的. (3认同)