Hi, Weldon Washburn <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> wrote: > On 3/9/07, Nathan Beyer <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 >
