|
From: Konstantin S. <kon...@gm...> - 2010-01-28 15:17:31
|
On Thu, Jan 28, 2010 at 1:02 PM, Julian Seward <js...@ac...> wrote: > On Thursday 28 January 2010, Konstantin Serebryany wrote: > > 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 see what you are saying. But overall I would much prefer to have > an annotation mechanism which can express exactly the set of inter-thread > dependencies, without adding any unnecessary ones. It may be mostly > of theoretical interest, but I think it is conceptually cleaner. From > the perspective of debugging and verifying the checkers, it's going to > be more difficult to reason about behaviour if the checkers are > dealing with a mixture of required and "fake" inter-thread dependencies. > Yeaaa. Still, I want a unit test were the current implementation hides a race. W/o a unittest, how do we test that the new implementation is correct (or at least better)? > > > 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. > > Maybe we should review the set to see if any are unneccessary. > There are two which are broken, I need to get rid of them. ANNOTATE_UNPUBLISH... is completely broken (bad idea) ANNOTATE_PUBLISH... is broken in case we are using literace-like sampling The rest are heavily used... > > > > 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? > > Mostly the latter. But once we can correctly annotate custom barriers, > exactly the same annotations should be usable to annotation > pthread_barrier_* > functions. So, really, "both". > > J > |