|
From: Julian S. <js...@ac...> - 2010-01-28 09:47:51
|
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. > 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. > 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 |