Re: [Valgrind-developers] Meaning of ANNOTATE_HAPPENS_{BEFORE, AFTER}

[Bart V. A. <bva...@ac...>]

On Wed, Jan 27, 2010 at 6:09 PM, Julian Seward <js...@ac...> wrote:
>
> [ ... ]
>
> IOW we need to deal in the worst case with an arbitrary delay between
> a thread leaving the barrier proper and having its state updated at
> the B_DEPART request.
>
> Hence I am now thinking instead of the following annotations:
>
>   B_INITIALISE(bar, int capacity)
>      initialise; state capacity
>
>   void* abstract_handle = B_ARRIVE(bar)
>      arrive at barrier.  obtain abstract handle (a VTS*, essentially) from
>      which we need to update when leaving
>
>   B_DEPART(bar, abstract_handle)
>      depart from barrier, updating our VTS using the one we were given
>      by B_ARRIVE

The above looks a lot better to me than instrumenting user-implemented
barriers via AH_BEFORE() and AH_AFTER(). While the latter approach is
sufficient for suppressing false positives triggered by a user barrier
implementation, these is a high risk that instrumenting
user-implemented barriers via AH_BEFORE() and AH_AFTER() will suppress
real races because these primitives introduce more inter-thread
ordering than barriers. The above proposal doesn't have that
disadvantage.

By the way, the "abstract_handle" is unnecessary in my opinion. Since
B_DEPART() will always be invoked from the same thread as the
corresponding B_ARRIVE() call, a threading tool can figure out which
B_DEPART() corresponds to B_ARRIVE() call by keeping a limited amount
of state information.

Bart.