pthread_cond_timedwait() broken in 9-stable? (from JAN 10)
Julian Elischer
julian at freebsd.org
Thu Feb 16 21:05:09 UTC 2012
On 2/16/12 9:34 AM, Andriy Gapon wrote:
> on 15/02/2012 23:41 Julian Elischer said the following:
>> The program fio (an IO test in ports) uses pthreads
>>
>> the following code (from fio-2.0.3, but its in earlier code too)
>> has suddenly started misbehaving.
>>
>> clock_gettime(CLOCK_REALTIME,&t);
>> t.tv_sec += seconds + 10;
>>
>> pthread_mutex_lock(&mutex->lock);
>>
>> while (!mutex->value&& !ret) {
>> mutex->waiters++;
>> ret = pthread_cond_timedwait(&mutex->cond,&mutex->lock,&t);
>> mutex->waiters--;
>> }
>>
>> if (!ret) {
>> mutex->value--;
>> pthread_mutex_unlock(&mutex->lock);
>> }
>>
>>
>> It turns out that 'ret' sometimes comes back instantly (on my machine) with a
>> value of 60 (ETIMEDOUT)
>> despite the fact that we set the timeout 10 seconds into the future.
>>
>> Has anyone else seen anything like this?
>> (and yes the condition variable attribute have been set to use the REALTIME clock).
> But why?
>
> Just a hypothesis that maybe there is some issue with time keeping on that system.
> How would that code work out for you with MONOTONIC?
Jens Axboe, (CC'd) tried both CLOCK_REALTIME and CLOCK_MONOTONIC, and
they both had the same problem..
i.e. random early returns with ETIMEDOUT.
I think we will try move out machine forward to a newer -stable to see
if it resolves.
More information about the freebsd-threads
mailing list