> > * In MSMProp1, isn't "Read" state similar to "ShR" and "Write"
> > > similar to "ShM" ?
> >
> > Similar, but not the same. Hence the different name to avoid phrases
> like
> > 'ShR from MSMHelgrind is different from ShR from MSMProp1 ... '
> > Also Sh in ShR/ShM means 'shared' while Read/Write are not necessary
> > shared.
>
> Fair enough. If I ignore the HB(SS,currS), then is it approximately
> correct to understand that "Write" means "last access was a write" and
> "Read" means "last access was a read" ?
Emm,
'Read' means that if there were writes to this memory location they all
'happened before' one of the reads.
'Write' means there were writes and this is not 'Read'.
>
>
> > > * I like that MSMProp1 removes E9/10/11/12 from MSMHelgrind.
> > > Those scanned all of memory and were potentially very expensive.
> >
> > We move this cost to handle_read/write, at least partially. But yes, I
> like
> > it too.
>
> You mean into the SS_update and LS_update "procedures" ? At least it
> is lazy, though -- presumably the cost only happens for locations which
> are later accessed.
>
Yes.
>
> > Not sure how to express it graphically in a more clear way...
>
> I would find the table a little clearer if it was like this:
>
> Edge OldState AccessType Condition NewState NewSegSet NewLockSet RaceIf
>
Sounds nice.
>
> Then the inputs to the FSM are clearly separated into cols 2,3,4 and
> the outputs to cols 5,6,7,8.
>
> Also, I was unclear if the transition rules as given exactly cover the
> possible input space exactly once?
> Or do I have to read from top to bottom and use the first rule that
> matches?
Yes. Sorry for ambiguity. I'll try to address it.
> At the moment I get the
> impression there is a hidden dependency, that E7 only applies if
> E6 does not apply -- I cannot just look at E7 by itself, and the input
> data I have, and see if it applies or not.
>
> > By 'pure happens-before detector' you understand the one which creates
> > happens-before relation after lock/unlock?
>
> Yes. Details posted already.
>
> 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
