On Wednesday 20 February 2008 22:07, Nicholas Nethercote wrote:
> On Wed, 20 Feb 2008, Julian Seward wrote:
> >>> 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?
> >>
> >> Sounds nice, but a very important task for data race detection tools
> >> is to detect which data is shared between threads unintentionally.
> >
> > For Helgrind-style schemes, data that is accessed only by one thread
> > stays in the exclusive state, and the state machine actions for exclusive
> > states are cheaper than for shared data, since there is no need
> > to do lockset intersections or threadset unions for Excl states.
> > So to some extent, there already is a less-expensive (I won't say fast
> > :-) handling case for data which is never shared.
>
> I think you're both missing the point. If you say "this memory shouldn't
> be shared", Helgrind could warn as soon as the memory leaves the exclusive
> state. Currently, Helgrind won't warn about memory shared unintentionally
> unless there's a race involved.
Ah. I did indeed miss the point.
Yes. So in effect it's a way for the program to communicate to the
checker, knowledge about properties of memory ("should always be
unshared") which it can check, and which it would not otherwise know.
Neat idea.
Typically only a small fraction of the memory in a program is shared;
most is unshared. It might be easier to turn it upside down, so the
tool is notified of areas which may be shared. Hmm. Not sure if
that is a good idea. It would give stronger checking but would
require exhaustively annotating all locations which might become
shared.
J
-------------------------------------------------------------------------
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
