Comment 1:

Owner changed to @rsc.

Status changed to Accepted.

Comment 2:

This is working as intended.  Just don't use Signal, because you can't tell which
goroutine it will awake.  Use Broadcast instead.

Status changed to WorkingAsIntended.

Comment 3:

There is only 1 goroutine waits on the cv, so it's pretty trivial to tell which
goroutine signal must awake.

Comment 4:

Here is the order of events for getting both locked up:
A) Thread 0 executes, stops in cv.wait()
B) Thread 1 executes, sets state to 1, calls cv.signal()
C) Thread 2 executes, stops in cv.wait()
D) Thread 2 unblocks, due to signal from (B)
E) Thread 2 loops, blocks again on cv.wait()
Deadlock, with two goroutines dead.  In this case, not even Broadcast will help.
There's actually an improvement we can make to avoid (C) happening when Signal() takes
the number of goroutines from 1 to 0, but in the end it still boils down to the
expectation of which goroutine Signal() is awakening.
That said, please post the snippet you have with real code.  I'll have a look at it.

Owner changed to @niemeyer.

Status changed to Thinking.

Comment 5:

Actually, I lied.  Using Broadcast would still solve the problem in this case,
because it's a real barrier that unblocks all existent goroutines.

Comment 6:

Here is the repro.
Please put it into src/sync/cond_test.go after fixing the issue.
import (
    . "sync"
    "testing"
    "runtime"
)
func TestCondWaitGenerations(t *testing.T) {
    procs := runtime.GOMAXPROCS(4)
    for i := 0; i < 1000; i ++ {
        var m Mutex
        c := NewCond(&m)
        state := 0
        go func() {
            m.Lock();
            for state == 0 {
                c.Wait()
            }
            state = 2
            c.Signal()
            m.Unlock()
        }()
        go func() {
            m.Lock()
            state = 1
            c.Signal()
            m.Unlock()
        }()
        go func() {
            for true {
                m.Lock()
                if (state != 0) {
                    for state != 2 {
                        c.Wait()
                    }
                } else {
                    break
                }
                m.Unlock()
            }
        }()
    }
    runtime.GOMAXPROCS(procs)
}

Comment 7:

> Here is the order of events for getting both locked up:
Indeed. That's what I meant. It should not happen.
"Signal wakes one goroutine waiting on c, if there is any.". So C) should be Thread 0
unblocks.

Comment 8:

Fair enough, I'll fix that.

Status changed to Accepted.

Comment 9:

The fix is up for review, with a simpler test case:
    http://golang.org/cl/4524083
Note that your example above has a bug: it's breaking out of the
for loop with a mutex held.

Status changed to Started.

Comment 10:

This issue was closed by revision 17bfa32.

Status changed to Fixed.