More quality quality

[Christopher James Halse Rogers]

On Tue, May 13, 2014 at 4:21 PM, Daniel van Vugt 
<daniel.van.vugt at canonical.com> wrote:
> The std::atomic issue is minor and well understood (helgrind only 
> understands critical sections implemented using pthread primitives). 
> We can either suppress std::atomic using valgrind rules or replace it 
> (less efficiently). That said, plenty of people using std::atomic are 
> actually writing racy code, which should be more correctly 
> implemented with a {condition_variable,mutex,bool} triplet.
> 
> As for std::condition_variable, that should be implemented as a 
> pthread_cond_t that helgrind fully understands... no? What false 
> positives have you seen from std::condition_variable?

It warns on broadcast with no blocked threads, which is not 
unreasonable but is also not actually an error.

It also gets confused when things interact with shared_ptr<>; if you 
have a std::condition_variable in something in a shared_ptr<> it will 
detect a race between deletion and waiting.

I've run it on my code occasionally, and each time it has generated 
pages of results, all of which have been false-positives.

It'd be great if we could trust it, but I don't think we can.