From owner-freebsd-threads@FreeBSD.ORG Thu Feb 16 17:45:38 2012 Return-Path: Delivered-To: threads@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id A45DA106566C for ; Thu, 16 Feb 2012 17:45:38 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citadel.icyb.net.ua (citadel.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id EC0878FC0C for ; Thu, 16 Feb 2012 17:45:37 +0000 (UTC) Received: from odyssey.starpoint.kiev.ua (beta-e.starpoint.kiev.ua [212.40.38.102]) by citadel.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id TAA23892; Thu, 16 Feb 2012 19:34:38 +0200 (EET) (envelope-from avg@FreeBSD.org) Message-ID: <4F3D3E2D.9090100@FreeBSD.org> Date: Thu, 16 Feb 2012 19:34:37 +0200 From: Andriy Gapon User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:10.0) Gecko/20120206 Thunderbird/10.0 MIME-Version: 1.0 To: Julian Elischer References: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> In-Reply-To: <4F3C2671.3090808__7697.00510795719$1329343207$gmane$org@freebsd.org> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Cc: threads@FreeBSD.org, FreeBSD Stable , Jens Axboe Subject: Re: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) X-BeenThere: freebsd-threads@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Threading on FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 17:45:38 -0000 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