|
From: Panagiotis F. <paf...@gm...> - 2011-05-15 17:37:23
|
Hello all. I have not been using valgrind (version 3.6.0) for a long time so please bear with me. I would like to ask 2 questions regarding helgrind. 1) Suppose that there is a global array named 'global_array'. Image the scenario where Thread1 does *global_array[0]*=value1 and Thread2 does * global_array[1]*=value2 without any protection. Clearly, that scenario does not cause any inconsistency problems. Is it possible that helgrind reports that scenario as a "Possible race"? 2) I have a C++ boost-threaded application. Threads read and write shared resources via GCC's atomic built-in operations, such as __sync_compare_and_swap, __sync_fetch_and_add and so forth. I would like to ask, whether or not helgrind is compatible with these kind of operations. Should I trust the races reported? I am asking because the exact same application was also written using pthreads for synchronization and helgrind reported no races at all in that (POSIX) implementation... Best Regards, Panagiotis Foteinos |
|
From: John R. <jr...@bi...> - 2011-05-15 17:59:36
|
> 1) Suppose that there is a global array named 'global_array'. Image the scenario where Thread1 does *global_array[0]*=value1 and Thread2 does *global_array[1]*=value2 without any protection. Clearly, that scenario does not cause any inconsistency problems. Is it possible that helgrind reports that > scenario as a "Possible race"? There cannot be a race unless there is at least one fetch from memory which could follow a store to memory. The example contains no fetches, therefore there cannot be a race. It is a bug if helgrind complains. -- |
|
From: Panagiotis F. <paf...@gm...> - 2011-05-15 18:54:57
|
Thank you for your response. Not sure what you mean however. If Thread1 did a read(global_array[0]) and Thread2 did a write(global_array[1]), then there is still no race. Or you mean that in that case helgrind would mistakenly report it as a race? Thank you, Panagiotis On Sun, May 15, 2011 at 1:59 PM, John Reiser <jr...@bi...> wrote: > > 1) Suppose that there is a global array named 'global_array'. Image the > scenario where Thread1 does *global_array[0]*=value1 and Thread2 does > *global_array[1]*=value2 without any protection. Clearly, that scenario does > not cause any inconsistency problems. Is it possible that helgrind reports > that > > scenario as a "Possible race"? > > There cannot be a race unless there is at least one fetch from memory > which could follow a store to memory. The example contains no fetches, > therefore there cannot be a race. It is a bug if helgrind complains. > > -- > > > ------------------------------------------------------------------------------ > 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 > |
|
From: John R. <jr...@bi...> - 2011-05-15 21:24:37
|
> 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. -- |
|
From: Panagiotis F. <paf...@gm...> - 2011-05-15 22:13:53
|
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 <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 > |
|
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 > > |
|
From: Julian S. <js...@ac...> - 2011-05-16 11:20:16
|
> 1) Suppose that there is a global array named 'global_array'. Image the > scenario where Thread1 does *global_array[0]*=value1 and Thread2 does * > global_array[1]*=value2 without any protection. Clearly, that scenario does > not cause any inconsistency problems. Is it possible that helgrind reports > that scenario as a "Possible race"? No. Since the addresses don't overlap, there is no race. > 2) I have a C++ boost-threaded application. Threads read and write shared > resources via GCC's atomic built-in operations, such as > __sync_compare_and_swap, __sync_fetch_and_add and so forth. I would like to > ask, whether or not helgrind is compatible with these kind of operations. Yes it is. > Should I trust the races reported? I am asking because the exact same > application was also written using pthreads for synchronization and > helgrind reported no races at all in that (POSIX) implementation... That normally means that Helgrind doesn't "see" the synchronisation events in the Boost library properly; see http://www.valgrind.org/docs/manual/hg-manual.html#hg-manual.effective-use point (1). I don't know whether Boost has options to be race-detector friendly. J |
|
From: Panagiotis F. <paf...@gm...> - 2011-05-16 17:09:15
|
I see. Thank you. So you are saying that although the GCC atomic operations are compatible with Helgrind, the fact that I use boost threads drive Helgrind crazy, correct? Regards, Panagiotis 2011/5/16 Julian Seward <js...@ac...>: > >> 1) Suppose that there is a global array named 'global_array'. Image the >> scenario where Thread1 does *global_array[0]*=value1 and Thread2 does * >> global_array[1]*=value2 without any protection. Clearly, that scenario does >> not cause any inconsistency problems. Is it possible that helgrind reports >> that scenario as a "Possible race"? > > No. Since the addresses don't overlap, there is no race. > >> 2) I have a C++ boost-threaded application. Threads read and write shared >> resources via GCC's atomic built-in operations, such as >> __sync_compare_and_swap, __sync_fetch_and_add and so forth. I would like to >> ask, whether or not helgrind is compatible with these kind of operations. > > Yes it is. > >> Should I trust the races reported? I am asking because the exact same >> application was also written using pthreads for synchronization and >> helgrind reported no races at all in that (POSIX) implementation... > > That normally means that Helgrind doesn't "see" the synchronisation > events in the Boost library properly; see > http://www.valgrind.org/docs/manual/hg-manual.html#hg-manual.effective-use > point (1). > > I don't know whether Boost has options to be race-detector friendly. > > J > |