> In this case however, what is reported is a concurrent write-after-read. Is that really a memory race?
In general, it would be: if these accesses are not synchronized, there's a risk that the goroutines could slip relative to each other so that the write and read take place at the same time, and the read sees an inconsistent value. In this particular case: if there's some external synchronization which means that the read is always strictly before the next write, then the problem may not occur in practice. I would be inclined to change newconns to atomic.Int32 <https://pkg.go.dev/sync/atomic#Int32> so it's safe either way, and the race detector should be silenced. On Thursday, 8 June 2023 at 08:24:56 UTC+1 burak serdar wrote: > On Wed, Jun 7, 2023 at 2:19 PM Sven Anderson <sv...@redhat.com> wrote: > >> >> >> Caleb Spare <ces...@gmail.com> schrieb am Mi. 7. Juni 2023 um 19:22: >> >>> On Wed, Jun 7, 2023 at 2:33 AM Sven Anderson <sv...@redhat.com> wrote: >>> > >>> > That’s not only a read/write race, it’s also a write/write race. Every >>> request to the server creates a new Go routine that might increment >>> newConns in parallel, so it may get corrupted. Same for lines 39/40. >>> > >>> > You might claim, that for infrastructural reasons, there can be no >>> concurrent requests to your server, but that would just mean that the race >>> is not triggered, it’s there nevertheless. >>> >>> The race detector reports on races that actually happened, not races >>> that could happen. >>> >> >> A race condition is a condition, not an event, so I think „happened“ is >> not correct, but maybe someone who knows the heuristics of the race >> detector better can clear that up. >> > > The race detector reports when shared memory is accessed concurrently from > multiple goroutines. So it detects when a memory race happens. In this case > however, what is reported is a concurrent write-after-read. Is that really > a memory race? > > >> >> And why would it matter then if it understands the causalities of TCP? >> One must be incorrect: Either your understanding of the TCP causalities or >> of how the race detector is working, because it does indeed report >> something, right? ;-) >> >> >> > >>> > Caleb Spare <ces...@gmail.com> schrieb am Mi. 7. Juni 2023 um 01:31: >>> >> >>> >> Can someone explain why the following test shows a race between the >>> >> indicated lines? >>> >> >>> >> >>> https://github.com/cespare/misc/blob/b2e201dfbe36504c88e521e02bc5d8fbb04a4532/httprace/httprace_test.go#L12-L43 >>> >> >>> >> The race seems to be triggered by the very last line of the test: >>> >> >>> >> get(client1) >>> >> >>> >> If I comment that out, then the race detector doesn't complain. But >>> >> then it seems that a read of a variable which happens before an HTTP >>> >> request which causes a write of the variable ultimately races with the >>> >> original read, which doesn't make sense. >>> >> >>> >> It seems like a false positive (perhaps the race detector doesn't >>> >> understand causality across a TCP connection?), but so far I've never >>> >> seen the race detector have a false positive, so I think I must be >>> >> missing something. >>> >> >>> >> I wrote a slightly simpler test (see TestHTTPRace2 right below in the >>> >> same file) which tries to make the race happen using a regular HTTP >>> >> handler and a single client and the race detector doesn't complain. >>> >> >>> >> Caleb >>> >> >>> >> -- >>> >> You received this message because you are subscribed to the Google >>> Groups "golang-nuts" group. >>> >> To unsubscribe from this group and stop receiving emails from it, >>> send an email to golang-nuts...@googlegroups.com. >>> >> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/golang-nuts/CAGeFq%2B%3DZGE5agaLYDgsdYvykbaWwHgjtKJf9q%2B1YJhR26%3DY45Q%40mail.gmail.com >>> . >>> >> >>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "golang-nuts" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to golang-nuts...@googlegroups.com. >> > To view this discussion on the web visit >> https://groups.google.com/d/msgid/golang-nuts/CAFwXxZTO0fsRRK%3DiShNL1xjbaXN7tDc8wN_uAy3J3FQXPwK7Pg%40mail.gmail.com >> >> <https://groups.google.com/d/msgid/golang-nuts/CAFwXxZTO0fsRRK%3DiShNL1xjbaXN7tDc8wN_uAy3J3FQXPwK7Pg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> > -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/50c3c2db-e2bf-45fe-905f-2b05a0970462n%40googlegroups.com.
