harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Xiao-Feng Li" <xiaofeng...@gmail.com>
Subject Re: [drlvm][threading] using a thread verification tool to find deadlock and race conditions
Date Sun, 11 Mar 2007 03:40:20 GMT
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.

Not necessarily useless, it still can be a good assistant tool. My
previous experience with Thread Checker did help me discover some real
hard bugs.

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

We need understand what are those "full benefit" DRLVM can get from
Thread Checker. And, as a system software, I assume the threading
infrastructure will not change dramatically once it's stable. So it
would be good if you can summarize the current status of DRLVM when
examined with Thread Checker.

I guess the current situation as you described is, DRLVM need to be
instrumented to really use Thread Checker's assistance. Before that,
most of the reported race conditions are false-positive, hence the
report is not very useful. We need break the cyclic dependence with
reasonable estimation on the potential efforts of the instrumentation
and the potential benefits.

My personal previous experience with Thread Checker was with parallel
application development, or application parallelization in C/C++. I am
not sure how Thread Checker can help a threading infrastructure
development, esp. when there exist dynamically generated code
sequence, and Java app has its own synchronization logic.

That being said, I think if the efforts are not huge and the
instrumentation doesn't impact much the code base, it would be
worthwhile to have a try, since we want Harmony to be rock solid in
threading part, any helping efforts should be appreciated, as long as
it does help.


> Thanks,
> Ilya Leviev
> Intel Enterprise Solutions Software Division

View raw message