code review 5919052: runtime: work around false negative in deadlock detection

runtime: work around false negative in deadlock detection

Not a complete fix for issue 3342, but fixes the trivial case.
There may still be a race in the instants before and after
a scavenger-induced garbage collection.

Intended to be "obviously safe": a call to runtime·gosched
before main.main is no different than a call to runtime.Gosched
at the beginning of main.main, and it is (or had better be)
safe to call runtime.Gosched at any point during main.

Update issue 3342.

[rsc, 2012-03-27 13:56:20]

Hello iant (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://go.googlecode.com/hg/

[iant, 2012-03-27 16:17:59]

LGTM

What about a test case for the problem with the earlier CL?  We could add that
later but let's not forget it.

[rsc, 2012-03-27 16:20:48]

On Tue, Mar 27, 2012 at 12:17,  <iant@golang.org> wrote:
> What about a test case for the problem with the earlier CL?  We could
> add that later but let's not forget it.

I don't actually know what the problem with the earlier CL was,
except that Mikio said it broke a test and I believed him.
But yes, we should add that test explicitly, later.

Russ

[rsc, 2012-03-27 16:22:21]

*** Submitted as http://code.google.com/p/go/source/detail?r=01acf1dbe91f ***

runtime: work around false negative in deadlock detection

Not a complete fix for issue 3342, but fixes the trivial case.
There may still be a race in the instants before and after
a scavenger-induced garbage collection.

Intended to be "obviously safe": a call to runtime·gosched
before main.main is no different than a call to runtime.Gosched
at the beginning of main.main, and it is (or had better be)
safe to call runtime.Gosched at any point during main.

Update issue 3342.

R=iant
CC=golang-dev
http://codereview.appspot.com/5919052

[mikio, 2012-03-27 16:33:25]

LGTM

On Wed, Mar 28, 2012 at 1:20 AM, Russ Cox <rsc@golang.org> wrote:

> I don't actually know what the problem with the earlier CL was,
> except that Mikio said it broke a test and I believed him.

Previous CL broke test/closure.go when you set GOMAXPROCS to gt 2.
Not sure the reason but test/closure.go failed w/ dying message "newfunc
allocated unexpectedly".

test/closure.go:
        runtime.ReadMemStats(memstats)
        if n0 != memstats.Mallocs {
                println("newfunc allocated unexpectedly")
                fail = true
        }