3

I thought of trying out thread sanitizer ( http://code.google.com/p/data-race-test/wiki/ThreadSanitizer#Using_ThreadSanitizer ) so I made a simple program:

#include <thread>
#include <atomic>
#include <vector>
#include <iostream>
#include <algorithm>
#include <mutex>
using namespace std;
int violated=0;
mutex mtx;
void violator()
{
    lock_guard<mutex> lg(mtx);
    violated++;
}
int main()
{
    thread t1(violator);
    t1.join();
    thread t2(violator);
    t2.join();
}

AFAIK program is OK since access to violated is synced with mutex(and like comments say even without that program is race free). But tsan complains and gives a bunch of warnings: http://www.filedropper.com/output So am I using the tool wrong, or is it not really good ? If important I'm using VS11 Beta.

NoSenseEtAl
  • 28,205
  • 28
  • 128
  • 277
  • 2
    The program would be correct even without any synchronisation... – Kerrek SB Apr 23 '12 at 02:37
  • I guessed so, I guess first join is enough... I just wanted to be sure. Ofc second join is needed. – NoSenseEtAl Apr 23 '12 at 02:47
  • Both joins are needed, but the way you have written it there's no concurrency. – Kerrek SB Apr 23 '12 at 03:05
  • I know, first I tried to just have an vector of threads that are joined later so there was a RC, and it was giving warnings like it should, but then I decided just to try normal nonRC case. – NoSenseEtAl Apr 23 '12 at 04:34

1 Answers1

12

This is normal, ThreadSanitizer does not know how to deal properly with the C++11 threading libraries, it also can't handle fine-grained synchronization using Interlocked* or std::atomic. Additionally the hybrid mode can produce false positives. You can build a suppression file to ignore races in the standard libraries and other false positives. Using your code on linux x64 and ThreadSanitizer I got 7 false races in the stdlib. After adding a suppression file I was able to ignore these races. Then I removed your lock and moved your t1.join() to after the start of the second thread (so there is a real race.) ThreadSanitizer detects this correctly. Then I added your mutex back in and the race was no longer reported. So it does in fact seem quite useful. Google uses it to find races in their Chrome browser, among many other projects, so it's quite mature (although building it on my ubuntu 12.10 system was a real pain.)

For linux my suppression file looks like:

{
<std::shared_ptr>
ThreadSanitizer:Race
...
fun:std::_Sp_counted_base::_M_release
fun:std::__shared_count::~__shared_count
fun:std::__shared_ptr::~__shared_ptr
}
{
<std::arena_thread_freeres>
ThreadSanitizer:Race
fun:arena_thread_freeres
fun:__libc_thread_freeres
fun:start_thread
}
Eloff
  • 20,828
  • 17
  • 83
  • 112
  • btw I dont expect C++11 support soon since *ing google code standard doesnt allow C++11. – NoSenseEtAl Oct 31 '12 at 11:07
  • 3
    On their project site, it's on the short-term todo list for ThreadSanitizer 2 (the new, faster version of TSan that uses LLVM, but only supports x64 linux atm.) – Eloff Oct 31 '12 at 15:15
  • cool, though after seeing this: http://www.chromium.org/developers/testing/threadsanitizer-tsan-v2 it looks like impossible to get it going without problems. :D – NoSenseEtAl Oct 31 '12 at 15:30
  • 1
    Just wanted to mention: this is a pretty old comment. Thread sanitizer correctly indicates no warnings in GCC 13.1. – Harry Williams Jun 19 '23 at 17:17