pthread_cond_timedwait超时后,线程是否拥有互斥锁?

Cin*_*air 2 multithreading posix pthreads condition-variable

线程调用后pthread_cond_timedwait,它返回ETIMEDOUT,线程是否拥有互斥锁?

我最初会认为不,但似乎我们必须pthread_mutex_unlockpthread_cond_timedwait回归后打电话ETIMEDOUT.

文件说:

成功返回后,互斥锁应被锁定并由调用线程拥有.

因此,在不成功返回(返回值!= 0)时,我认为互斥锁不属于.

但是,如果我们不叫pthread_mutex_unlockETIMEDOUT,互斥似乎是一个破碎的状态(即我不能让另一个线程来收购它,它只是档).

该文档也暗示了这一点,因为它们总是解锁互斥锁,无论返回值如何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);
Run Code Online (Sandbox Code Playgroud)

那么,线程总是在获得互斥量之后pthread_cond_timedwait?它实际上没有意义,因为为了再次获取互斥锁,调用必须阻止超过指定的时间.

caf*_*caf 5

您正在查看较旧的POSIX问题. 问题7有这个澄清的文字:

当发生这样的超时时,pthread_cond_timedwait()仍应释放并重新获取互斥锁引用的互斥锁,并且可能消耗同时指向条件变量的条件信号.

如果它在这种情况下没有重新获取互斥锁,你必须在调用代码中重新获取它,这样你就可以在超时后重新测试条件,因为你可能已经消耗了一个条件信号.只有在您没有发生等待条件发生超时时才应将其视为超时情况.

超时并不能防止持有时间过长的互斥锁,它可以防止未能及时到达的状态信号(通常,互斥锁只应保持在相对确定的短暂时段,而等待的条件可能是受外部投入的影响).