Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com
Message-ID: <022d01c40aee$cc520cc0$800101df@toyon.corp>
From: "Peter J. Stieber" <developer AT toyon DOT com>
To: <cygwin AT cygwin DOT com>
References: <20040313171440 DOT GA7326 AT redhat DOT com> <c34on3$h5a$1 AT sea DOT gmane DOT org> <20040315173318 DOT GB23853 AT redhat DOT com>
Subject: Re: latest snapshot seems better wrt make -j hang problems
Date: Mon, 15 Mar 2004 16:36:56 -0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes

> I wonder if there is a super-secret club out there somewhere that I can
> now join having spent the last four months wrapping my head around
> subtle multi-threaded race conditions.  My wife has not quite picked up
> on the fact that when I have a certain pained intense look on my face,
> I'm really trying to model what happens when two threads attack the same
> area of code at the same time rather than suffering from some sort of
> intestinal disorder.
>
> FWIW, I found ANOTHER race yesterday while running the cygwin test
> suite.  So, it's back to square one for testing since it was in low
> level code which could affect everything.  And, this race has been there
> since I screwed up in September 2001.  Lovely.

I've been watching your debugging efforts in this area and I feel you pain.
I'm not sure this will help, but if I were you I would be getting desperate
for help.

From the Valgrind website:

Helgrind [part of Valgrind] is a thread debugger which finds data races in
multithreaded programs. It looks for memory locations which are accessed by
more than one (POSIX p-)thread, but for which no consistently used
(pthread_mutex_)lock can be found. Such locations are indicative of missing
synchronization between threads, and could cause hard-to-find
timing-dependent problems. It is useful for any program that uses pthreads.
It is a somewhat experimental tool, so your feedback is especially welcome
here.

Do you think it would be worth the effort of attempting to build this thing
under cygwin?

If you think it's worth it, I could take a stab at building it for you.

Feel free to be mean. I probably deserve it ;-)
Pete


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/