From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2117 invoked by alias); 27 Oct 2009 09:43:17 -0000 Received: (qmail 2109 invoked by uid 22791); 27 Oct 2009 09:43:16 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Oct 2009 09:43:12 +0000 Received: (qmail 3494 invoked from network); 27 Oct 2009 09:43:10 -0000 Received: from unknown (HELO orlando) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 27 Oct 2009 09:43:10 -0000 From: Pedro Alves To: Paul Pluzhnikov Subject: Re: [patch] Fix for PR gdb/10757 Date: Tue, 27 Oct 2009 09:43:00 -0000 User-Agent: KMail/1.9.10 Cc: gdb-patches@sourceware.org References: <20091015191037.4091D76761@ppluzhnikov.mtv.corp.google.com> <200910262135.00507.pedro@codesourcery.com> <8ac60eac0910261741y3db8faekb7aef4305d6c2e4d@mail.gmail.com> In-Reply-To: <8ac60eac0910261741y3db8faekb7aef4305d6c2e4d@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200910270943.33164.pedro@codesourcery.com> X-IsSubscribed: yes 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: 2009-10/txt/msg00655.txt.bz2 On Tuesday 27 October 2009 00:41:24, Paul Pluzhnikov wrote: > > static __volatile__ int thread_iteration_in_progress; > static __volatile__ int thread_creation_in_progress; > > __pthread_create_2_1 (...) > { > while (thread_iteration_in_progress) nanoslep ...; > atomic_increment(&thread_creation_in_progress); > ... create new thread, put it on thread list ... > atomic_decrement(&thread_creation_in_progress); > return ... > } > > and in > > td_ta_thr_iter () > { > set thread_iteration_in_progress in the inferior to 1 > while (thread_creation_in_progress in inferior > 0) > nanosleep ... > > iterate over the thread lists ... > > set thread_iteration_in_progress in inferior to 0 > } > This does make the race window narrower, but it doesn't completely kill it, as new threads could have passed the thread_iteration_in_progress check already as gdb enters the thread iteration loop. -- Pedro Alves