pthread_cond_timedwait() broken in 9-stable? (from JAN 10)
Julian Elischer
julian at freebsd.org
Thu Feb 16 22:55:47 UTC 2012
On 2/16/12 1:06 PM, Julian Elischer wrote:
> 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.
Kan upgraded the machine today to today's 9.x branch tip and the
problem still occurs.
8.x does not have this problem.
I have not got a 9-RELEASE machine to test on.. so I can not tell if
this came in with the burst of stuff
that came in after the 9.x branch was unfrozen after the release of 9.0.
>
>
> _______________________________________________
> freebsd-threads at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-threads
> To unsubscribe, send any mail to
> "freebsd-threads-unsubscribe at freebsd.org"
>
More information about the freebsd-stable
mailing list