pthread_cond_timedwait超时后,线程是否拥有互斥锁?
Posted
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了pthread_cond_timedwait超时后,线程是否拥有互斥锁?相关的知识,希望对你有一定的参考价值。
一个线程调用pthread_cond_timedwait
后,它返回ETIMEDOUT
,线程是否拥有互斥锁?
我最初认为不,但似乎我们必须在pthread_mutex_unlock
返回pthread_cond_timedwait
之后调用ETIMEDOUT
。
成功返回后,互斥锁应被锁定并由调用线程拥有。
因此,在不成功返回(返回值!= 0)时,我认为互斥锁不属于。
但是,如果我们不在pthread_mutex_unlock
之后调用ETIMEDOUT
,则互斥锁似乎处于破坏状态(即我无法获得另一个线程来获取它,它只是停止)。
文档也暗示了这一点,因为无论pthread_cond_timedwait
的返回值是什么,它们总是解锁互斥锁:
(void) pthread_mutex_lock(&t.mn);
t.waiters++;
clock_gettime(CLOCK_REALTIME, &ts);
ts.tv_sec += 5;
rc = 0;
while (! mypredicate(&t) && rc == 0)
rc = pthread_cond_timedwait(&t.cond, &t.mn, &ts);
t.waiters--;
if (rc == 0) setmystate(&t);
(void) pthread_mutex_unlock(&t.mn);
那么,线程是否总是在pthread_cond_timedwait
之后获得互斥量?它实际上没有意义,因为为了再次获取互斥锁,调用必须阻止超过指定的时间。
您正在查看较旧的POSIX问题。 Issue 7有这个澄清的文字:
当发生这样的超时时,
pthread_cond_timedwait()
仍然会释放并重新获取互斥锁引用的互斥锁,并且可能会消耗同时指向条件变量的条件信号。
如果它在这种情况下没有重新获取互斥锁,你必须在调用代码中重新获取它,这样你就可以在超时后重新测试条件,因为你可能已经消耗了一个条件信号。只有在您没有发生等待条件且发生超时时才应将其视为超时情况。
超时并不能防止持有时间过长的互斥锁,它可以防止未能及时到达的状态信号(通常,互斥锁应该只保持短暂的,相对确定的时段,而等待的条件可能是受外部投入的影响)。
以上是关于pthread_cond_timedwait超时后,线程是否拥有互斥锁?的主要内容,如果未能解决你的问题,请参考以下文章
C++ 11 替代 pthread_cond_timedwait
JNI 环境中 pthread_cond_broadcast() 和 pthread_cond_timedwait() 的等效函数是啥?
Linux多线程编程 - sleep 和 pthread_cond_timedwait
Linux C语言 pthread_cond_wait()pthread_cond_timedwait()函数(不允许cond被唤醒时产生竞争,所以需要和互斥锁搭配)
Azure 应用服务Azure Function HTTP 触发后, 230秒就超时。而其他方式触发的Function, 执行5分钟后也超时,如何调整超时时间?