Date: Thu, 16 Feb 2012 16:42:34 -0800 From: Julian Elischer <julian@freebsd.org> To: Andriy Gapon <avg@freebsd.org> Cc: Alexander Kabaev <kan@freebsd.org>, threads@freebsd.org, FreeBSD Stable <freebsd-stable@freebsd.org>, David Xu <davidxu@freebsd.org> Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) Message-ID: <4F3DA27A.3090903@freebsd.org> In-Reply-To: <4F3D89CD.9050309@freebsd.org> References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org> <4F3D89CD.9050309@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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.
>>>>
>>>> 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.
>
>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3DA27A.3090903>