|
From: Bart V. A. <bva...@ac...> - 2010-03-08 19:08:39
|
On Mon, Mar 8, 2010 at 4:44 PM, Julian Seward <js...@ac...> wrote: > > [ ... ] > > But I think we should just forget them, and stay with > ANNOTATE_HAPPENS_BEFORE and ANNOTATE_HAPPENS_AFTER. > > The motivation was for the correct annotation of barriers directly using > h-b edges. But it's better to directly do so with ANNOTATE_BARRIER_*. > > The original idea was that, for a barrier, we have some abstract sync > object (the barrier) which needs to acquire an h-b edge from each incoming > thread. Then, when all the threads leave the barrier, they all take > a h-b dependency from the sync object. > > So for the thread-arrival handling, ANNOTATE_HAPPENS_BEFORE is not the > correct thing for the 2nd and subsequent arriving threads, because it > throws away any previous h-b edge associated with the barrier. What we > need is to accumulate h-b edges in the barrier; in VTS terms take the > join (vector max) of all the VTSs of the threads arriving at the barrier. > Hence the distinction between A_H_B_OVERWRITE(x), which copies the calling > thread's VTS into 'x', and A_H_B_ACCUMULATE(x), which joins the calling > thread's VTS into 'x'. I'm not sure I understood the above completely. What I understood about happens-before, happens-after annotations and barriers is as follows: * The effect of a happens-after annotation is that a new segment is created with as vector clock the maximum of the vector clock of the current thread and the vector clocks of the most recent matching happens-before annotations of all other threads. Any other implementation would make the reference counting annotation example in http://code.google.com/p/data-race-test/source/browse/trunk/dynamic_annotations/dynamic_annotations.h incorrect. * Annotating barriers with happens-before/after annotations is too complex to bother a user with. If I'm not mistaken it is possible to annotate POSIX barriers as follows with happens-before/after annotations (where b is a pointer to a pthread_barrier_t object and i is a thread-local integer variable with the same scope as the pthread_barrier_t object and initialized to zero): ANNOTATE_HAPPENS_BEFORE((char*)b + i) result = pthread_barrier_wait(b); ANNOTATE_HAPPENS_AFTER((char*)b + i) i = (i + 1) % 2; The complexity of the above is a compelling argument for me to introduce specific annotations for barriers. Notes: - The above annotation style is only correct if each time the same set of threads participates in the barrier. Annotating barriers with happens-before/after annotations is even more complex when the set of threads that participates in the barrier can vary. - Inserting ANNOTATE_HAPPENS_BEFORE(b) before each pthread_barrier_wait(b) call and ANNOTATE_HAPPENS_AFTER(b) after each pthread_barrier_wait(b) call is racy. There is a significant probability that not all ANNOTATE_HAPPENS_AFTER() annotations of the current barrier will have been invoked before the first ANNOTATE_HAPPENS_BEFORE() annotation of the next barrier is invoked. Bart. |