tree f487de9d0a0fe87f557adeee844aa70f3e3734f0
parent 31f71506d7026595be76713af25197a8c0022ac8
author Daniel S Fava <danielsfava@gmail.com> 1605198347 +0100
committer Ian Lance Taylor <iant@golang.org> 1605279623 +0000

runtime: swap the order of raceacquire() and racerelease()

In chansend() and chanrecv() of chan.go, the order of calls to
raceacquire() and racerelease() was swapped, which meant that the
code was not following the memory model "by the letter of the law."
Similar for bufrecv and bufsend in select.go

The memory model says:

- A send happens before the corresponding receive completes, and
- the kth receive on a channel with capacity C happens before the
k+C send on that channel completes.

The operative word here is "completes."  For example, a sender obtains
happens-before information on completion of the send-operation, which
means, after the sender has deposited its message onto the channel.
Similarly for receives.

If the order of raceacquire() and racerelease() is incorrect, the race
detector may fail to report some race conditions.

The fix is minimal from the point of view of Go.  The fix does, however,
rely on a new function added to TSan:

https://reviews.llvm.org/D76322

This commit only affects execution when race detection is enabled.

Added two tests into `runtime/race/output_test.go`:

- `chanmm` tests for the issue addressed by this patch
- `mutex` is a test for inverted semaphores, which must not be broken
  by this (or any other) patch

Fixes #37355

Change-Id: I5e886879ead2bd456a4b7dd1d17253641b767f63
Reviewed-on: https://go-review.googlesource.com/c/go/+/220419
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Go Bot <gobot@golang.org>
Trust: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Dmitry Vyukov <dvyukov@google.com>