[Prev] Thread [Next]  |  [Prev] Date [Next]

Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) Julian Elischer Thu Feb 16 17:00:45 2012

Adding David Xu for his thoughts since he reqrote the code in quesiton in revision 213098

On 2/16/12 2:57 PM, Julian Elischer wrote:
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.

         t.tv_sec += seconds + 10;


         while (!mutex->value&&  !ret) {
ret = pthread_cond_timedwait(&mutex->cond,&mutex->lock,&t);

         if (!ret) {

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.

[EMAIL PROTECTED] mailing list
To unsubscribe, send any mail to "[EMAIL PROTECTED]"