>
> So this increases the granularity by treating larger sections of memory as
> a
> single thing?
No. It just ignores large portion of memory locations (thus missing some
races).
What you suggest will also lead to speedup, but will show races where there
is no race actually, but likely a false sharing.
>
>
> But programmers should know in advance which bits of memory should be
> shared. Perhaps some client requests could be used which say "this
> section
> of memory will be shared" or "this section of memory won't be shared"
> could
> be useful. In the "won't be shared" sections the checking might be a lot
> simpler?
>
Yes, I was also thinking about such requests.
But in order to be helpful they must cover a large portion of all accesses
(in dynamic).
Also, we will have to put all these addresses into some map/hash_map/cache
which may also be expensive.
One more idea I am going to try:
Consider we want to debug only some part of a large program. Then we can
simply ignore all memory accesses done in other parts of program.
Helgrind could have a command line option saying 'handle only those accesses
that happen when execution stack contains FOO() or BAR()'
--kcc
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Valgrind-developers mailing list
Valgrind-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/valgrind-developers
