From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <frysk-return-2546-listarch-frysk=sources.redhat.com@sourceware.org>
Received: (qmail 11670 invoked by alias); 23 Nov 2007 09:41:05 -0000
Received: (qmail 11663 invoked by uid 22791); 23 Nov 2007 09:41:05 -0000
X-Spam-Status: No, hits=-1.1 required=5.0 	tests=AWL,BAYES_00,DK_POLICY_SIGNSOME,FORGED_RCVD_HELO,WLS_URI_OPT_0
X-Spam-Check-By: sourceware.org
Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (83.160.170.119)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 23 Nov 2007 09:41:00 +0000
Received: from dijkstra.wildebeest.org ([192.168.1.29]) 	by gnu.wildebeest.org with esmtp (Exim 4.63) 	(envelope-from <mark@klomp.org>) 	id 1IvV1t-0005CL-Pe; Fri, 23 Nov 2007 10:40:58 +0100
Subject: Re: [SCM]  master: Avoid spurious waits in CountDownLatch.await
From: Mark Wielaard <mark@klomp.org>
To: frysk@sourceware.org
Cc: Tim Moore <timoore@redhat.com>
In-Reply-To: <20071122205327.10260.qmail@sourceware.org>
References: <20071122205327.10260.qmail@sourceware.org>
Content-Type: text/plain
Date: Fri, 23 Nov 2007 09:41:00 -0000
Message-Id: <1195810857.2981.6.camel@dijkstra.wildebeest.org>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.1 (2.12.1-3.fc8)
Content-Transfer-Encoding: 7bit
X-Spam-Score: -1.4 (-)
X-IsSubscribed: yes
Mailing-List: contact frysk-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <frysk.sourceware.org>
List-Subscribe: <mailto:frysk-subscribe@sourceware.org>
List-Post: <mailto:frysk@sourceware.org>
List-Help: <mailto:frysk-help@sourceware.org>, <http://sourceware.org/lists.html#faqs>
Sender: frysk-owner@sourceware.org
X-SW-Source: 2007-q4/txt/msg00167.txt.bz2

Hi Tim,

On Thu, 2007-11-22 at 20:53 +0000, moore@sourceware.org wrote:
>     2007-11-22  Tim Moore  <timoore@redhat.com>
>     
>     	* CountDownLatch.java (await): Loop to avoid spurious wakeup.

Using wait() and notify() are such a pain :{
Good you caught this one.
Using higher order concurrent primitives is good.

There are some other non-guarded wait()s in some of the stepping command
(StepInstructionCommand, StepNextCommand, StepNextiCommand), which all
have something like:

      synchronized (cli.steppingObserver.getMonitor())
        {
          try
            {
              //XXX This looks racy.
              cli.steppingObserver.getMonitor().wait();
            }
          catch (InterruptedException ie) {}
        }

The XXX comment is right :{

If you are cleaning this up anyway you might want to abstract away all
the logic about guarding the mutex into the steppingObserver.

Cheers,

Mark