Date: Thu, 16 Feb 2012 19:34:37 +0200 From: Andriy Gapon <avg@FreeBSD.org> To: Julian Elischer <julian@FreeBSD.org> Cc: threads@FreeBSD.org, FreeBSD Stable <freebsd-stable@FreeBSD.org>, Jens Axboe <jaxboe@fusionio.com> Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) Message-ID: <4F3D3E2D.9090100@FreeBSD.org> In-Reply-To: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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?
--
Andriy Gapon
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4F3D3E2D.9090100>