More quality quality

[Daniel van Vugt]

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?

- Daniel


On 13/05/14 13:55, Christopher James Halse Rogers wrote:
> On Tue, May 13, 2014 at 1:52 PM, Daniel van Vugt
> <daniel.van.vugt at canonical.com> wrote:
>> All,
>>
>> I'd like (in the somewhat distant future) for us to be able to run
>> Mir's tests under helgrind [1] so that we can automatically detect
>> races in continuous integration.
>>
>> It's not going to be a short journey, as there's a fair amount of
>> errors to fix yet. They're mostly benign but the noise easily hides
>> real bugs. So in the mean time, if you write any new code that crosses
>> multiple threads, please try to run your individual test cases under
>> helgrind and check no new races are being introduced.
>
> If we want to use helgrind seriously we should probably fix some of its
> more glaring shortcomings. In particular, it doesn't understand
> std::atomic and doesn't appear to understand std::condition_variable,
> which means it generates a _lot_ of false positives for code that's
> transparently correct.
>