|
From: Julian S. <js...@ac...> - 2011-03-13 12:59:02
|
On Sunday, March 13, 2011, Bart Van Assche wrote:
> On Sun, Mar 13, 2011 at 1:10 PM, Julian Seward <js...@ac...> wrote:
> > I think it would be useful to separate the question of why a race
> > is reported in the original version from the question of how to fix
> > it. So, first of all, do you agree with my analysis of why the
> > race is reported -- because the atomic load/store is concurrent with
> > the delete ?
>
> Not completely. What the tools are reporting IMHO is that there is no
> tool-visible h-b arc between the atomic decrement in one thread and
> freeing memory in another thread. So the test program is fine but the
> race report is a false positive. The reason I posted this on the list
> is that I haven't found a solution yet for letting a data race
> detection tool recognize that pattern without introducing new
> annotations.
Err, I think we're agreeing. Problem was imprecise wording on
my part, sorry. To clarify:
I agree that the test program (original version) doesn't have
a race.
I agree also that the race reported in the original program is
a false positive, due to the reason you mention.
I am wondering if this is an atomicity problem. Perhaps what we
need is the decrement and creation of the h-b edge to be atomic.
I say this because (as we seem to have established) neither the
original ordering
U_ANNOTATE_HAPPENS_BEFORE(m_count_ptr);
int new_count = --(*m_count_ptr);
if (new_count == 0)
nor the version I proposed
int new_count = --(*m_count_ptr);
U_ANNOTATE_HAPPENS_BEFORE(m_count_ptr);
if (new_count == 0)
are exactly correct.
J
|