harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leviev, Ilia A" <ilia.a.lev...@intel.com>
Subject RE: [drlvm][threading] using a thread verification tool to find deadlock and race conditions
Date Tue, 13 Mar 2007 14:35:25 GMT

Hi,

Weldon Washburn <weldonwjw@gmail.com> wrote:

>Ilia, can you tell us the impact on behavior/performance of
>both release build and debug build?  

Weldon, No impact on behavior/performance of both release build and
debug build if switch <ITCH> is unset.


>I suspect the tool will show both false alarms
>as well as missed detections.

False alarms are to be marked in a source code by Thread Checker API.


>If you have a summary of the 30 places, perhaps you can
>post it.

Here is Thread Checker results that have checked Harmony 
which run Hello World:
______________________________________________________
|Source code	              |Number of occurrences|
|_______________________________|_____________________|
|nt_exception_filter_common.cpp | 3 -data-races
|_______________________________|_____________________|
|cg.cpp	                    | 6 -data-races
|_______________________________|_____________________|
|mem_alloc.cpp	              | 5 -data-races
|_______________________________|_____________________|
|thread_native_thin_monitor.c	| 3 -data-races
|_______________________________|_____________________|
|type.h	                    | 3 -data-races
|_______________________________|_____________________|
|hashtable.h	              | 2 -data-races
|_______________________________|_____________________|
|compiler.cpp	              | 10 -data-races
|_______________________________|_____________________|
|object_handles.cpp	        | 15 -data-races
|_______________________________|_____________________|
|drljitinterface.cpp	        | 3 -data-races
|_______________________________|_____________________|
|thread_ti_others.c	        | 3 -data-races
|_______________________________|_____________________|

See more detailed description of one compiler.cpp data-races in JIRA
HARMONY-3371.


Thanks,
Ilya Leviev
Intel Enterprise Solutions Software Division



On 3/10/07, Weldon Washburn <weldonwjw@gmail.com> wrote:
> 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
>

Mime
View raw message