<?xml version="1.0" encoding="UTF-8"?>
<!-- Generated on Wed, 23 May 2012 10:29:01 -0700 -->
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <atom:link href="http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic/feed/" rel="self" type="application/rss+xml" />
    <title>Intel Software Network Comments Feed</title>
    <link>http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic</link>
    <description></description>
    <language>en-us</language>
    <item>
      <title>By Dmitriy Vyukov</title>
      <description><![CDATA[ Hmmm... How Inspector may detect a data race on a TBB atomic? Does Inspector allow false-positives? If so, then do they specific to TBB atomics or they related to the underlying method of verification?
 ]]></description>
      <link>http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic/#comment-21117</link>
      <pubDate>Wed, 18 Mar 2009 00:19:54 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic/#comment-21117</guid>
    </item>
    <item>
      <title>By Dmitriy Vyukov</title>
      <description><![CDATA[ Regarding Win32 Interlocked, how Inspector treats loads of variables? There is no InterlockedRead(), so it's common practice to just load the variable.
 ]]></description>
      <link>http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic/#comment-21119</link>
      <pubDate>Wed, 18 Mar 2009 00:22:44 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic/#comment-21119</guid>
    </item>
    <item>
      <title>By Dmitriy Vyukov</title>
      <description><![CDATA[ Does Inspector detect races when one thread uses 32-bit Interlocked function on a memory location and another thread uses 64-bit Interlocked function on the same memory location (actual addresses may differ by 32-bits)?
 ]]></description>
      <link>http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic/#comment-21121</link>
      <pubDate>Wed, 18 Mar 2009 00:29:52 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic/#comment-21121</guid>
    </item>
    <item>
      <title>By Eric Moore (Intel)</title>
      <description><![CDATA[ Intel Parallel Inspector does not know if you used TBB, OpenMP, or Inerlocked... functions.  It examines the binary, if the binary has one thread using a .LOCK# extension on the assembly instruction and one thread is using one of the many ways to read a variable .....  then it reports a data race.

This may or may not be a true data race, you will have to analyze the code/binary yourself to determine.

From a language/library perspective - there is no way to "read" a memory variable safely with Interlocked.. functions, or OpenMP....  but, you could do ...
CurrentAtomicVal=InterlockedAdd(&AtomicVar,0)
or
#pragma omp atomic
AtomicVal+=0;

But, "I don't think" that is common practice...(and I haven't even tried it).  I think the common practice is to depend on the fact that the architecure and compiler - generally make reads atomic.  This is an unsafe assumption - but that is what is done. 

A better practice for OpenMP and Interlocked... is when updating your Atomic Variable - you assign the new value to a variable which is private to the thread. - and that is the value you read within your thread -not what is at the memory location pointed to by your original variable. (Note: Do not update/read the atomic variable into the private variable, update the private memory variable, and assing it back to the original - as that would be an atomicity violation)

"I think" the best solution is to use the Atomic<> construct provided by TBB - (or with something similiar).  And I beleive the new constructs that are being worked into the upcoming C/C++ specs to support atomics will also be good. ]]></description>
      <link>http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic/#comment-21160</link>
      <pubDate>Wed, 18 Mar 2009 11:27:52 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic/#comment-21160</guid>
    </item>
    <item>
      <title>By Dmitriy Vyukov</title>
      <description><![CDATA[ Ok, thank you, so Inspector works on the binary level. ]]></description>
      <link>http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic/#comment-21170</link>
      <pubDate>Wed, 18 Mar 2009 14:01:02 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic/#comment-21170</guid>
    </item>
    <item>
      <title>By Dmitriy Vyukov</title>
      <description><![CDATA[ Will not it give too many false-positives with such approach?..
Every "CAS loop" contains read of the variable... And many algorithms based on just atomic reads and writes...

Re: "I think" the best solution is to use the Atomic<> construct provided by TBB - (or with something similiar). And I beleive the new constructs that are being worked into the upcoming C/C++ specs to support atomics will also be good.

But std::atomic<>::load() will emit NON LOCKed load of the data, so Inspector will report a race, right? 
 ]]></description>
      <link>http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic/#comment-21172</link>
      <pubDate>Wed, 18 Mar 2009 14:09:24 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic/#comment-21172</guid>
    </item>
    <item>
      <title>By Eric Moore (Intel)</title>
      <description><![CDATA[ Intel Parallel Inspector is likely to report a data race when the user uses std::atomic::load() ... depending on how the compiler/library implements that function on IA32/Intel64.  I believe that the engineers are still researching/confirming/debating the appropriate instructions to implement ::load() on IA32/Intel64.

From a Language/Library perspective using c++ std::atomic::load() - will eventually be safe. - and if you look at the assembly and it is using a single instruction to load the memory (i.e: the compiler isn't doing something illegal/bad) - then you can safely suppress the data-race warning in Intel Parallel Inspector using the suppresion feature.

As to the frequency of reporting false positives - I can not guess.  But note: just because somebody is using atomics - does not mean they did it right (remember there are both architecture and compiler issues - just looking at the assembly for the Interlocked function or omp atomic statement is not enough - you need to make sure the compiler did the "right" thing for all the surrounding variables: do you require Serial consistency for example).  Semantically, using c++00x or TBB atomics - it is easier to make sure that every read/write is safe.  Semantically - you need to use Interlocked.. .functions in Win32 and atomics in OpenMP - else it won't be atomic. ]]></description>
      <link>http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic/#comment-21181</link>
      <pubDate>Wed, 18 Mar 2009 15:08:59 -0700</pubDate>
      <guid isPermaLink="true">http://software.intel.com/en-us/articles/data-race-identified-on-atomic-construct-win32-interlocked-functions-pragma-omp-atomic-or-atomic/#comment-21181</guid>
    </item>
  </channel></rss>
