On 2012/09/21 02:44:10, rsc wrote:
On Thu, Sep 20, 2012 at 10:36 PM, Dmitry Vyukov
All memory accesses must be instrumented. make(chan int, n) and
others are
just not implemented yet.

There are (at least) 2 quirks.
1. raceread() (or racewrite()) must be executed iff the memory
access is
executed. That's why && and || are not currently instrumented. The
transformation of && would be:
if(a) {
yield true;
yield false;

And note that a&&b may appear in switch case or as a nested function
argument (foo(..., bar(..., a&&b, ...), ...)).
We have the same kinds of problems hoisting function calls out of a &&
b. See case OANDAND around walk.c:504 and its use of a separate list
and addinit. You should be able to do something similar.
2. raceread/racewrite can't be reordered with function calls
function calls can contain synchronization).
E.g. if we have
foo(bar(), a);
it's *incorrect* to transform it just to:
foo(bar(), a);
because bar() is sequenced before read of a, and can e.g. lock a
mutex (thus
preventing race on a).
So the correct transformation would be along the lines of:
x = bar();
foo(x, a);
Actually the read of a is not sequenced compared to the call of bar.
Only function calls and communication operations are sequenced. In
this example 'a' can be evaluated in either order. However, builtins
count as function calls, so if a were 'len(a)' the call to len would
be sequenced but the evaluation of a would not, if that makes sense.
I'm happy with this code as is, mostly, but please separate the bottom
list of cases into ones that you expect to ignore forever (such as
print or println) and ones that are just unimplemented. Please mark
the latter block:
// unimplemented
goto ret;
or something like that. Thanks.

Done. PTAL.
I am not sure right now what exactly cases does not require
instrumentation, so I moved only the obvious ones.


Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-dev @
postedSep 22, '12 at 4:03a
activeSep 22, '12 at 4:03a

1 user in discussion

Dvyukov: 2 posts



site design / logo © 2022 Grokbase