|
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 > |