|
From: Julian S. <js...@ac...> - 2010-01-27 16:24:07
|
> > But this doesn't work well, and I think it's not clear what semantics
> > you intended for these two.
> >
> > This situation I can understand:
> >
> > T1: AH_BEFORE(obj)
> > T2: AH_AFTER(obj)
> >
> > then we get an edge T1->T2
> >
> > But what about this?
> >
> > T1: AH_BEFORE(obj)
> > T2: AH_BEFORE(obj)
> > T3: AH_AFTER(obj)
> >
> > Should we get edges T1->T3 and T2->T3,
>
> Yes, we will get two edges.
> The h-before events are never forgotten. (ThreadSanitizer forgets them when
> it flushes the entire state)
I don't think it is good that the behaviour AH_BEFORE is hardwired
in this way. It makes the annotation set inflexible. What do you
think of the following proposal?
AH_BEFORE_OVERWRITE(obj)
forget everything in obj, then acquire a h-b dep from caller
AH_BEFORE_ACCUMULATE(obj)
merge in a h-b dep from caller; don't forget history
so your AH_BEFORE == AH_BEFORE_ACCUMULATE
AH_AFTER(obj)
acquire h-b edges from obj (unchanged)
A_FORGET(obj)
forget everything
You may not find A_FORGET and AH_BEFORE_OVERWRITE useful, but at least
there presence (+ clarification of the semantics) makes it more
flexible and controllable.
Also, I'd like to propose new annotations for barriers. We can annotate
barriers in terms of the above 4, but that hardwires the assumption that
the underlying checker has a concept of h-b edges. I'd prefer a set
of macros which merely specify the state of the barrier:
B_RESET(bar)
state that nobody is waiting for the barrier
B_ARRIVE(bar)
i have arrived at the barrier
B_DEPART(bar, Bool i_am_the_last_to_depart)
i have left the barrier, and give an indication of whether or
not I am the last to leave. (If so, the checker would
probably want to behave like B_RESET).
J
|