|
From: Miguel O. <mig...@gm...> - 2011-05-15 22:32:48
|
Hi, On Mon, May 16, 2011 at 12:13 AM, Panagiotis Foteinos <paf...@gm...> wrote: > 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. Your original message had asterisks. It was encoded in both HTML (with <b> tags, etc.) and "simple HTML" (with asterisks). Please use plain text. > > 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... Can you please post a full .c example, including helgrind's and gcc's versions? I can't reproduce your findings with a simple example I coded. Regards, Miguel > > > Regards, > Panagiotis > > > On Sun, May 15, 2011 at 5:24 PM, John Reiser <jr...@bi...> 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 >> Val...@li... >> 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 > Val...@li... > https://lists.sourceforge.net/lists/listinfo/valgrind-users > > |