Date: Thu, 16 Feb 2012 22:13:32 +0100 From: Jens Axboe <jaxboe@fusionio.com> To: Julian Elischer <julian@freebsd.org> Cc: Kabaev <kan@freebsd.org>, "threads@freebsd.org" <threads@freebsd.org>, FreeBSD Stable <freebsd-stable@freebsd.org>, Andriy Gapon <avg@freebsd.org>, Alexander Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) Message-ID: <4F3D717C.9040309@fusionio.com> In-Reply-To: <4F3D6FDD.9050808@freebsd.org> References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> <4F3D3E2D.9090100@FreeBSD.org> <4F3D6FDD.9050808@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2012-02-16 22:06, 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.
Yep indeed, using either MONOTONIC or REALTIME (and having set both with
pthread_condattr_setclock()), no change in behaviour.
--
Jens Axboe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3D717C.9040309>
