From owner-freebsd-stable@FreeBSD.ORG Wed Feb 15 21:39:41 2012 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E26E01065673 for ; Wed, 15 Feb 2012 21:39:41 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) by mx1.freebsd.org (Postfix) with ESMTP id B699F8FC17 for ; Wed, 15 Feb 2012 21:39:41 +0000 (UTC) Received: from julian-mac.elischer.org (c-67-180-24-15.hsd1.ca.comcast.net [67.180.24.15]) (authenticated bits=0) by vps1.elischer.org (8.14.4/8.14.4) with ESMTP id q1FLdZcI009369 (version=TLSv1/SSLv3 cipher=DHE-RSA-CAMELLIA256-SHA bits=256 verify=NO); Wed, 15 Feb 2012 13:39:40 -0800 (PST) (envelope-from julian@freebsd.org) Message-ID: <4F3C2671.3090808@freebsd.org> Date: Wed, 15 Feb 2012 13:41:05 -0800 From: Julian Elischer User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10.4; en-US; rv:1.9.2.26) Gecko/20120129 Thunderbird/3.1.18 MIME-Version: 1.0 To: threads@freebsd.org, FreeBSD Stable Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: Jens Axboe Subject: pthread_cond_timedwait() broken in 9-stable? (from JAN 10) X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Feb 2012 21:39:42 -0000 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).