More quality quality

[Daniel van Vugt]

I trust helgrind after using it for years... it always won the argument 
despite not being able to easily answer "what's wrong with my code?". 
The eraser algorithm is extremely reliable and provably correct. 
Although we don't always understand the errors it reports, that's a 
human problem :)

If there are some "safe races" floating around, I think it's worth the 
pain to be forced to assess and deal with them individually.


On 13/05/14 14:34, Christopher James Halse Rogers wrote:
> 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.
>