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: local policy)
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Subject: RE: [drlvm][threading] using a thread verification tool to find
 deadlock and race conditions
Date: Fri, 9 Mar 2007 19:41:52 +0300
Message-ID: <300B70C65DCD59468957941A60716EBC5EB525@mssmsx411>
In-Reply-To: <3b3f27c60703090806g66ff9dd7xfb915f992c80d926@mail.gmail.com>
Thread-Topic: [drlvm][threading] using a thread verification tool to find
 deadlock and race conditions
Thread-Index: AcdiZPJD+kaMzAQQTVyBQCfi0N6B8gAAwnVg
From: "Leviev, Ilia A" <ilia.a.leviev@intel.com>
To: <dev@harmony.apache.org>


Nathan,

I think we need to introduce additional build configuration switch to be
able to compile this Thread Checker API calls.

Thanks,
Ilya Leviev

-----Original Message-----
From: nbeyer@gmail.com [mailto:nbeyer@gmail.com] On Behalf Of Nathan
Beyer
Sent: Friday, March 09, 2007 7:06 PM
To: dev@harmony.apache.org
Subject: Re: [drlvm][threading] using a thread verification tool to find
deadlock and race conditions

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

-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
>