Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (herse.apache.org: domain of weldonwjw@gmail.com designates
 64.233.182.185 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:references;
        b=o+aj/f24AM5khHG6+SgZOMHL/JqLmA61w/ztJmrewRa8TBQoO7K5YpyCndCjfdCN/HOqy+n7ftKzBSeEIvfcT6nKFDk2QbVprlEBTOqGBhS8DwUMxWsknJ5i/59GnvLf1MecUlH1n4CJuM7oIQqpKXiC6y+jWipHbjM9Depkk0Q=
Message-ID: <4dd1f3f00703101142y450f1cabpec1a76ad0ee58146@mail.gmail.com>
Date: Sat, 10 Mar 2007 11:42:45 -0800
From: "Weldon Washburn" <weldonwjw@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [drlvm][threading] using a thread verification tool to find
 deadlock and race conditions
In-Reply-To: <3b3f27c60703090806g66ff9dd7xfb915f992c80d926@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_6262_13948827.1173555765904"
References: <300B70C65DCD59468957941A60716EBC5EB446@mssmsx411>
	 <3b3f27c60703090806g66ff9dd7xfb915f992c80d926@mail.gmail.com>

------=_Part_6262_13948827.1173555765904
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

On 3/9/07, Nathan Beyer <ndbeyer@apache.org> wrote:

> How invasive would this be? Would it be always present or a special build?


Good point.  Ilia, can you tell us the impact on behavior/performance of
both release build and debug build?  Also, you mention some 30 places where
there are race conditions.  I suspect the tool will show both false alarms
as well as missed detections.  (Otherwise the technology could be repurposed
to solve the Holy Grail of threading -- automatic application
parallelization.)  If you have a summary of the 30 places, perhaps you can
post it.  If not, how about posting the entire output of the Thread Checker
tool.   If its more than 150 lines long, how about putting it in a JIRA
unless you think Wiki would be a better place.  It would be good to have a
discussion on the value of this tool's output.

If we are to imbed Thread Checker specific code in drlvm, we need to get an
idea how much engineering effort this requires.  And who would do this
work.  And justify this work given there are other, competing demands.  I am
in favor of tools that help us improve stability.  However, the use of
Thread Checker is not my decision alone.


> -Nathan
>
> On 3/9/07, Leviev, Ilia A <ilia.a.leviev@intel.com> wrote:
> >
> > Hi,
> > I have started using http://intel.com/thread_checker_download.zip to
> > find deadlock and race conditions in the VM.
> >
> > First I have checked Harmony which run Hello World
> > Application and tool have detected about 30 race conditions. But on some
> > DRLVM kernel tests it shows several hundred problems.
> >
> > There some problem of tracking Harmony code by the Thread Checker.
> > The reason for this is that the Intel Thread Checker supports
> > interpretation only of standard APIs for Windows and POSIX threading.
> > Any specially built synchronization constructs that are not part of
> > Windows
> > API or POSIX API are not normally tracked by the Thread Checker.
> > However, the Thread Checker includes the User-Level Synchronization API
> > that to help gather information related to user-defined synchronization
> > constructs.
> > Thus if we use our own synchronization we should inform Thread Checker
> > runtime about it. Otherwise the tool will generate incorrect diagnostics
> > and will be useless for us.
> >
> > In other words, to gain full benefit from Thread Checker, the VM
> > developers will need to embed thread checker calls in the
> > synchronization code.  Should we put this on the harmony development
> > schedule for Q2?
> >
> >
> > Thanks,
> > Ilya Leviev
> > Intel Enterprise Solutions Software Division
> >
>


-- 
Weldon Washburn
Intel Enterprise Solutions Software Division

------=_Part_6262_13948827.1173555765904--