That looks like a race between reading the length of the channel and writing to the channel. That looks like a correct report to me.

@randall77 Thanks for looking at this. Commenting out the assertion on the channel length doesn't change things, so I don't think that's what is causing the report. I could be wrong, obviously, but considering what statements are being referred to in the report, len(cCh) doesn't show up

It would help if you could provide complete stand-alone code for the problem, and if the race report that you show corresponds to that code.

That said, I see that (*Broker).Send starts a goroutine. In TestRace I see that the code calls (*Broker).Send three times. That starts three goroutines. If I'm reading your mocking code correctly, it calls wg.Done as soon as the calling code calls s.C, which is to say as soon as the goroutine enters the select statement. So the goroutine calls wg.Done when it enters the select statement, but before it chooses any case from the select statement. Then TestRace reads from the channel. While I can't claim to understand this code, it seems possible that after reading from the channel, the select statement sends to the channel. And then TestRace closes the channel. There is no synchronization between that send and that close, so you get a race report.

The len(cCh) is the access that caused the race in the report you showed us. At least, assuming broker_test.go you gave us and stuff_test.go you ran with are identical.
If there is still a race without that line, show us that updated race report.
(It will probably be on the close(cCh) because that also races with the channel send.)

@ianlancetaylor The mock .Do() function that calls wg.Done() is invoked after the mock has returned the channel. I've created a repo with the code so it's easy to recreate the issue: https://github.com/EVODelavega/go-race

The channel is closed after the wg is done, so after the channel was returned to the 3 routines. The routines run sequentially by definition (each routine requires a mutex lock), so only the last call to Send could be the time a data race happens. Then again, the wg.Wait call makes sure that the routine has indeed called sub.C(). Between my waiting for the waitgroup, and my closing the channel, I close the done channel, read from the channel, check its length, etc... and still, the data race is reported. The only way to get around it is to make an explicit call to the broker, removing the mock, which acquires a lock, and thus wait for the go routine to return.

@randall77 As you can see in the repo I created: the code to reproduce the issue is indeed identical to what I posted here. the len(cCh) statement is 100% not a data race, just looking at the language specifications:

A single channel may be used in send statements, receive operations, and calls to the built-in functions cap and len by any number of goroutines without further synchronization. Channels act as first-in-first-out queues. For example, if one goroutine sends values on a channel and a second goroutine receives them, the values are received in the order sent.

checking length and cap of a channel doesn't require synchronisation, so there is no data race possible there. The closing of the channel is where the race detector takes issue with, unless I remove the mock from the broker first. The issue I have is that: the behaviour of the unit tests, and indeed the broker are 100% deterministic. I use the waitgroup for synchronisation, and close(dCh) is not flagged up. Of course, the routines only read from the done channel, but looking at the coverage rapport: this case is never selected anyway, and instead I see the broker outputs "Skipped broker 1" twice (which tells me the select executed the default case).

Try as I like, to me there's only 2 ways around this issue:

• After the wg.Wait() statement, I have to make a second call to the broker (Unsubscribe or Subscribe), which acquires a mutex lock, ensuring the routines have returned, or call Send a fourth time after closing the dCh. In both cases, it really does feel like I'm appeasing the race detector, because -as I keep saying- the behaviour of the code is deterministic to the best of my knowledge.
• Never close the channel, but that's just bad form

the len(cCh) statement is 100% not a data race, just looking at the language specifications:

You're right, this is not a race. Why then did it report the line number of the len call?
Your repro reports the close call on the next line.

I agree with Ian. The compiler converts:

select {
case ...:
case s.C() <- v:
}

To

tmp := s.C()
select {
case ...:
case tmp <- v:
}

In between the assignment and the select statement, the wait group can be decremented to 0 (inside the 3rd C call), allowing the main routine to run to the close statement and cause a race with the select case.