Hi, On Sun, 4 Jan 2015 14:18:59, Mike Stump wrote: > >> But tsan still gets at least 90% chance to spot that. As a matter of fact, >> the tsan runtime is just _incredibly_ fast, >> and catches errors, with a very high reliability. But it is racy by design. > > You say by design. I’m skeptical of that. Can you quote the email or the code > were they said I wanted to design a system that wasn’t 100% reliable, because > the best they could do was 2% slower, and they didn’t want it to be 2% > slower? I tend to think someone didn’t figure out they could atomically, > locklessly do the update, or they didn’t understand the performance hit on > the lockless code was small, or worse, they had no clue it was racy. I’d be > curious to know. Maybe, there are other complications that prevent it from > being non-racy. >
see for instance this thread "Is TSan an exact tool?": https://groups.google.com/forum/#!topic/thread-sanitizer/mB73m6Nltaw When I say "by design" I did not mean to say something negative on the code quality. It is an excellent design. One of the design principles is speed. We are able to use TSan to successfully test complex communication protocols. If it would slow down the execution more than absolutely necessary it would be useless. > Using sleep goes back decades, and I think that style should have mostly died > around 1987 or so. It’s 2015, and I’d rather consider it an obsolete style, > exclusive of hard real-time. I bring it up, as I’ve been burned by sleep and > people that think sleep is a nice solution. The sleep(1) is only in the positive test cases. That is obviously not the best possible solution. ... And it makes the test suite run at least 10 seconds longer... :-) Nevertheless I would prefer to silence the test now with sleep(1), And come back later with a follow-up patch to use a un-instrumented and non-interceptable synchronization primitive in all tsan tests. As it is at least not obvious how to do that in the test suite. But it must be possible. Bernd.
