|
From: Bart V. A. <bva...@ac...> - 2010-01-28 07:32:49
|
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. |