|
From: Siddharth N. <si...@gm...> - 2012-07-17 19:56:20
|
Hi, I'm trying to write a new Valgrind tool that tracks thread synchronization. Is there any way to identify which variables are shared or which memory address range is shared amongst multiple threads? Siddharth |
|
From: Siddharth N. <si...@gm...> - 2012-07-17 21:21:38
|
Hi Bart, I should explain further. I'm trying to record the synchronization events between threads by monitoring the memory locations that multiple threads read/write. By post processing this information with a simple cache simulation I'm hoping to analyze coherence traffic. I'm trying to narrow down the number of memory locations to monitor. DRD documentation says the pthreads model assumes that all memory within a process is assumed to be shared by all threads belonging to that process. However, most threaded programs require you to either declare shared variables or manually use locks around them. Is there any way to detect this early (i.e. before threads are spawned) so that tracking memory addresses becomes more tractable? I'm not familiar with the DRD or Valgrind core code (I am reasonably familiar with the Callgrind code), but if similar/same functionality already exists in DRD, it'd be a great help if you could point me in the right direction. Siddharth On 17 July 2012 16:09, <ba...@ba...> wrote: > > I'm trying to write a new Valgrind tool that tracks thread > > synchronization. > > Is there any way to identify which variables are shared or which memory > > address range is shared amongst multiple threads? > > Isn't that what's already being tracked by the conflict set data structure > in DRD ? > > Bart. > > |
|
From: Siddharth N. <si...@gm...> - 2012-08-13 05:40:00
|
Hi All, Any word on this? When Valgrind encounters a memory address read/write, is there any mechanism that can tell us if the address is shared among threads? Sid On 17 July 2012 17:21, Siddharth Nilakantan <si...@gm...> wrote: > Hi Bart, > > I should explain further. I'm trying to record the synchronization events > between threads by monitoring the memory locations that multiple threads > read/write. By post processing this information with a simple cache > simulation I'm hoping to analyze coherence traffic. I'm trying to narrow > down the number of memory locations to monitor. > > DRD documentation says the pthreads model assumes that all memory within a > process is assumed to be shared by all threads belonging to that process. > However, most threaded programs require you to either declare shared > variables or manually use locks around them. Is there any way to detect > this early (i.e. before threads are spawned) so that tracking memory > addresses becomes more tractable? I'm not familiar with the DRD or Valgrind > core code (I am reasonably familiar with the Callgrind code), but if > similar/same functionality already exists in DRD, it'd be a great help if > you could point me in the right direction. > > Siddharth > > On 17 July 2012 16:09, <ba...@ba...> wrote: > >> > I'm trying to write a new Valgrind tool that tracks thread >> > synchronization. >> > Is there any way to identify which variables are shared or which memory >> > address range is shared amongst multiple threads? >> >> Isn't that what's already being tracked by the conflict set data structure >> in DRD ? >> >> Bart. >> >> > |
|
From: Julian S. <js...@ac...> - 2012-08-16 07:05:31
|
> Any word on this? When Valgrind encounters a memory address read/write, is > there any mechanism that can tell us if the address is shared among > threads? I don't think so. Both DRD and Helgrind track this indirectly, but not AFAICS in a way which makes it easy to find out whether the memory is shared. For example, Helgrind keeps track of vector clock constraints on when the next "safe" read and write for the location can be, and DRD (I'd guess) keeps a set of bitmaps for "uncompleted" thread segments that shows which memory locations have been accessed in those segments. You might be better off implementing some kind of shadow memory arrangement which tracks the sharedness state of each cache line, a kind of MESI protocol in software. For shadow memory implementations you might find this useful: http://valgrind.org/docs/shadow-memory2007.pdf J |
|
From: Siddharth N. <si...@gm...> - 2012-08-16 18:06:46
|
On 16 August 2012 02:54, Julian Seward <js...@ac...> wrote: > > > Any word on this? When Valgrind encounters a memory address read/write, > is > > there any mechanism that can tell us if the address is shared among > > threads? > > I don't think so. Both DRD and Helgrind track this indirectly, but not > AFAICS in a way which makes it easy to find out whether the memory is > shared. > For example, Helgrind keeps track of vector clock constraints on when the > next "safe" read and write for the location can be, and DRD (I'd guess) > keeps a set of bitmaps for "uncompleted" thread segments that shows which > memory locations have been accessed in those segments. > > I see. I was also looking into the option of using LL/SC or IRCAS occurences as a hint about recent address locations being shared. From the translated statements, is there anyway to tell whether it is a mutex or barrier operation? I'm guessing not. You might be better off implementing some kind of shadow memory arrangement > which tracks the sharedness state of each cache line, a kind of MESI > protocol > in software. For shadow memory implementations you might find this useful: > http://valgrind.org/docs/shadow-memory2007.pdf > > Thanks for the link. So you are suggesting I do the cache simulation on the fly instead of in post processing. Callgrind/Cachegrind already seem to do cache simulations. Would it not be possible to simply extend them for coherence and for multiple threads? Would that be less complex than doing shadow memory management from scratch? > J > |
|
From: Julian S. <js...@ac...> - 2012-08-21 10:16:59
|
> Callgrind/Cachegrind already seem to do cache simulations. Would it not be > possible to simply extend > them for coherence and for multiple threads? Would that be less complex > than doing shadow memory > management from scratch? Yeah, you could also extend the cache simulation -- that might be wiser. But I am only guessing here -- I don't really know. Maybe better to see if JosefW has anything to say on the subject. J |