|
From: Konstantin S. <kon...@gm...> - 2010-01-28 07:47:28
|
I agree that the current annotations used to implement barrier support in ThreadSanitizer *may* *in theory* hide some races. But I would like to see an example where it really hides them. And then, I would like to see a *realistic* example. :) I agree that AH_BEFORE_OVERWRITE and A_FORGET might be needed in some cases. (but again, I'd like to see a *realistic* test where the current annotations hide a race) But the problem with the annotations is that we already have too many of them and the users are sometimes confused. Also, are we talking here about implementing barrier support inside a tool (helgrind, drd, tsan, etc) or about exporting these annotations to users so that they can use it for their custom barriers? One other thing. I think, for the semantics of the annotations to make sense generally, you need to say that, although the checker may run the threads concurrently, it must process each annotation atomically. It sounds like hair splitting, I know, but .. it's hard to see what the effect would be if processing of annotations was allowed to happen concurrently. good point :) --kcc On Thu, Jan 28, 2010 at 10:32 AM, Bart Van Assche <bva...@ac...>wrote: > 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. > |