From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20556 invoked by alias); 12 Feb 2013 17:23:11 -0000 Received: (qmail 20548 invoked by uid 22791); 12 Feb 2013 17:23:09 -0000 X-SWARE-Spam-Status: No, hits=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_HOSTKARMA_NO X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 12 Feb 2013 17:23:04 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id E16991C7893; Tue, 12 Feb 2013 12:23:03 -0500 (EST) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ngE9sCfwjuLX; Tue, 12 Feb 2013 12:23:03 -0500 (EST) Received: from joel.gnat.com (localhost.localdomain [127.0.0.1]) by rock.gnat.com (Postfix) with ESMTP id AFFF91C7806; Tue, 12 Feb 2013 12:23:03 -0500 (EST) Received: by joel.gnat.com (Postfix, from userid 1000) id 8E606C0431; Tue, 12 Feb 2013 09:23:01 -0800 (PST) Date: Tue, 12 Feb 2013 17:23:00 -0000 From: Joel Brobecker To: Jan Kratochvil Cc: gdb-patches@sourceware.org Subject: Re: [patch] testsuite: pthread_cond_wait.exp: Avoid a race Message-ID: <20130212172301.GH17107@adacore.com> References: <20130212170358.GA5633@host2.jankratochvil.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130212170358.GA5633@host2.jankratochvil.net> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2013-02/txt/msg00279.txt.bz2 > It is just too racy. I will check in the easy workaround below, it is > sure not a real fix. 2 seconds feels much much much too long, however. I try to avoid these types of delays, because collectively they make a significant dent on the overall amount of time it takes to run the testsuite. I am trying to think of a way to rewrite the program to avoid the delay entirely, but I don't think it's possible, because we need to the thread to run until it blocks in pthread_cond_wait. Can we try a smaller value? For instance, if we went from 0.01 second to 0.1 seconds, we'd increase the time by a factor of 10. In today's CPU times, 0.1 second enough to do a huge amount of processing, no? -- Joel