summaryrefslogtreecommitdiff
path: root/test/chan/doubleselect.go
AgeCommit message (Collapse)AuthorFilesLines
2012-04-06Imported Upstream version 1upstream/1Ondřej Surý1-3/+3
2011-09-13Imported Upstream version 60upstream/60Ondřej Surý1-0/+86
2011-09-13Imported Upstream version 60Ondřej Surý1-86/+0
2011-02-14Imported Upstream version 2011-02-01.1upstream/2011-02-01.1Ondřej Surý1-17/+19
2010-03-30single argument panicRuss Cox1-1/+2
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 http://codereview.appspot.com/850041
2009-12-18runtime: fix race conditionAdam Langley1-0/+83
(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 http://codereview.appspot.com/180068