On 29 Jun 2014 at 21:16, Adam Romanek wrote:
I'd like to draw your attention to an issue with Boost.Atomic that I encountered when using ThreadSanitizer. The problem is that when using the code shown in "reference counting" example [1] from the docs, the ThreadSanitizer reports a data race. Everything is described in detail in a StackOverflow thread [2] so I don't want to repeat all that here.
Please help me determine whether it's a false positive, an issue in Boost.Atomic or a wrong usage of the code.
I'd try replacing boost::atomic with std::atomic and see if the same thing happens. Oh, and use a recent libstdc++. If it's only happening in Boost, report it as a bug.
Additionally, I don't understand this:
Write of size 1 at 0x7d040000f7f0 by thread T2: #0 operator delete(void*) <null>:0 (a.out+0x00000004738b)
What kind of write does ThreadSanitizer might refer to?
ThreadSanitiser tracks bounds of change, so if only one byte of change overlaps the raced bounds then it'll get reported as one byte. tl;dr I wouldn't worry about it. ThreadSanitiser has many weirdness due to its design and straight out bugs. I am currently awaiting clang 3.5 release because 3.4 won't fully backtrace when libstdc++'s reference counted std::string has false positived a race, and I have dozens of workaround suppressions for it. Roll on libstdc++ 4.10 and its new std::string implementation!!! Niall -- ned Productions Limited Consulting http://www.nedproductions.biz/ http://ie.linkedin.com/in/nialldouglas/