1
0
mirror of https://github.com/golang/go synced 2024-11-25 00:47:56 -07:00
Commit Graph

4 Commits

Author SHA1 Message Date
Russ Cox
4bdf1fc02b test: silence/coalesce some tests
Add copyright notice to nilptr.go.

R=golang-dev, r
CC=golang-dev
https://golang.org/cl/5139048
2011-09-26 19:35:21 -04:00
Russ Cox
0a5fc261b6 test/chan/doubleselect: fix various races
There were duplicate closes and missing closes,
with the result that the program was rarely testing
as much as it seemed to be.  Now it finishes.

R=r
CC=golang-dev
https://golang.org/cl/4008046
2011-01-21 15:06:44 -05:00
Russ Cox
00f9f0c056 single argument panic
note that sortmain.go has been run through hg gofmt;
only the formatting of the day initializers changed.
i'm happy to revert that formatting if you'd prefer.

stop on error in doc/progs/run

R=r
CC=golang-dev
https://golang.org/cl/850041
2010-03-30 10:34:57 -07:00
Adam Langley
50d6c81d4a runtime: fix race condition
(Thanks to ken and rsc for pointing this out)

rsc:
	ken pointed out that there's a race in the new
	one-lock-per-channel code.  the issue is that
	if one goroutine has gone to sleep doing

	select {
	case <-c1:
	case <-c2:
	}

	and then two more goroutines try to send
	on c1 and c2 simultaneously, the way that
	the code makes sure only one wins is the
	selgen field manipulation in dequeue:

	       // if sgp is stale, ignore it
	       if(sgp->selgen != sgp->g->selgen) {
		       //prints("INVALID PSEUDOG POINTER\n");
		       freesg(c, sgp);
		       goto loop;
	       }

	       // invalidate any others
	       sgp->g->selgen++;

	but because the global lock is gone both
	goroutines will be fiddling with sgp->g->selgen
	at the same time.

This results in a 7% slowdown in the single threaded case for a
ping-pong microbenchmark.

Since the cas predominantly succeeds, adding a simple check first
didn't make any difference.

R=rsc
CC=golang-dev
https://golang.org/cl/180068
2009-12-18 12:25:53 -08:00