Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
runtime: make checking if tracing is enabled non-atomic
Tracing is currently broken when using iter.Pull from the rangefunc experiment partly because the "tracing is off" fast path in traceAcquire was deemed too expensive to check (an atomic load) during the coroutine switch. This change adds trace.enabled, a non-atomic indicator of whether tracing is enabled. It doubles trace.gen, which is the source of truth on whether tracing is enabled. The semantics around trace.enabled are subtle. When tracing is enabled, we need to be careful to make sure that if gen != 0, goroutines enter the tracer on traceAcquire. This is enforced by making sure trace.enabled is published atomically with trace.gen. The STW takes care of synchronization with most Ms, but there's still sysmon and goroutines exiting syscalls. We need to synchronize with those explicitly anyway, which luckily takes care of trace.enabled as well. When tracing is disabled, it's always OK for trace.enabled to be stale, since traceAcquire will always double-check gen before proceeding. For #61897. Change-Id: I47c2a530fb5339c15e419312fbb1e22d782cd453 Reviewed-on: https://go-review.googlesource.com/c/go/+/565935 Auto-Submit: Michael Knyszek <mknyszek@google.com> LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com> Reviewed-by: Michael Pratt <mpratt@google.com>
- Loading branch information