Thank you John.
I did not write HTML code, just plain text. My original message had no
asterisks. For mysterious reasons, you mail reader sees the apostrophe as an
asterisk.
So, let me rewrite the last 2 separate scenarios (yes, they are separate,
sorry for the confusion) without apostrophes this time.
________________________________________
Scenario1:
Thread1: global_array[0] = value1;
Thread2: global_array[1] = value2;
________________________________________
________________________________________
Scenario2:
Thread1: global_array[0] = value1;
Thread2: int value = global_array[1];
________________________________________
Both scenarios have no actual races. Different memory locations.
My question is whether or not helgrind reports mistakenly a race. In my
application, helgrind reports a race for Scenario2 and I am trying to
understand why...
Regards,
Panagiotis
On Sun, May 15, 2011 at 5:24 PM, John Reiser <[email protected]> wrote:
> > Not sure what you mean however.
>
> The characters in the original message were
> * global_array[0] *= value1;
> * global_array[1] *= value2;
> except there were no spaces and no semicolons. This is unclear.
> Why the leading star '*' before "global_array"?
> My mail reader interpreted this in "Simple HTML" as asking for bold font
> with straight assignment (no "multiply in place"), as if the HTML markup:
> <b>global_array[0]</b> = value1;
> <b>global_array[1]</b> = value2;
> As such, there are no fetch operations, therefore no races.
> If helgrind complains, then that is a bug in helgrind.
>
>
> > If Thread1 did a read(global_array[0]) and Thread2 did a
> write(global_array[1]), then there is still no race.
>
> Again, this is unclear. Do you intend those two operations to be a new
> separate example, or do you intend to append those operations to the
> original scenario? Please write (in C code as text, not HTML) the
> complete,
> exact code that you mean.
>
> If those two operations are a separate, complete scenario, then Yes,
> there still is no race. A race requires a write and a read of the
> same location. The locations of the write and the read differ,
> so there can be no race. If helgrind complains, then that is a bug in
> helgrind.
>
> --
>
>
> ------------------------------------------------------------------------------
> Achieve unprecedented app performance and reliability
> What every C/C++ and Fortran developer should know.
> Learn how Intel has extended the reach of its next-generation tools
> to help boost performance applications - inlcuding clusters.
> http://p.sf.net/sfu/intel-dev2devmay
> _______________________________________________
> Valgrind-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/valgrind-users
>
------------------------------------------------------------------------------
Achieve unprecedented app performance and reliability
What every C/C++ and Fortran developer should know.
Learn how Intel has extended the reach of its next-generation tools
to help boost performance applications - inlcuding clusters.
http://p.sf.net/sfu/intel-dev2devmay
_______________________________________________
Valgrind-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/valgrind-users
