aboutsummaryrefslogtreecommitdiff
path: root/src/sync
AgeCommit message (Collapse)Author
2022-05-19all: gofmt main repoRuss Cox
Excluding vendor and testdata. CL 384268 already reformatted most, but these slipped past. The struct in the doc comment in debug/dwarf/type.go was fixed up by hand to indent the first and last lines as well. For #51082. Change-Id: Iad020f83aafd671ff58238fe491907e85923d0c7 Reviewed-on: https://go-review.googlesource.com/c/go/+/407137 Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org> Auto-Submit: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com>
2022-05-08sync: remove the redundant logic on sync.(*Pool).PutJason7602
When the procUnpin is placed after shared.pushHead, there is no need for x as a flag to indicate the previous process. This CL can make the logic clear, and at the same time reduce a redundant judgment. Change-Id: I34ec9ba4cb5b5dbdf13a8f158b90481fed248cf5 Reviewed-on: https://go-review.googlesource.com/c/go/+/360059 Reviewed-by: Ian Lance Taylor <iant@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com> Reviewed-by: David Chase <drchase@google.com> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-05-06sync/atomic: don't run 64-bit uintptr tests on 32-bit systemsIan Lance Taylor
The tests don't work on big-endian systems. This change handles more of the tests added in CL 381317 like the other existing tests. Fixes #52723 Change-Id: Ie9e048e75dbe0b5aca61b51cd0c50d7d878ff6d6 Reviewed-on: https://go-review.googlesource.com/c/go/+/404495 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Bryan Mills <bcmills@google.com> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@golang.org> Auto-Submit: Ian Lance Taylor <iant@google.com>
2022-05-04sync/atomic: add typed atomic valuesRuss Cox
These implementations will inline to the lower-level primitives, but they hide the underlying values so that all accesses are forced to use the atomic APIs. They also allow the use of shorter names (methods instead of functions) at call sites, making code more readable. Pointer[T] also avoids conversions using unsafe.Pointer at call sites. Discussed on #47141. See also https://research.swtch.com/gomm for background. Fixes #50860. Change-Id: I0b178ee0c7747fa8985f8e48cd7b01063feb7dcc Reviewed-on: https://go-review.googlesource.com/c/go/+/381317 Reviewed-by: Michael Pratt <mpratt@google.com> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-29sync/atomic: use consistent first-store-in-progress markerKeith Randall
We need to use the same marker everywhere. My CL to rename the marker (CL 241661) and the CL to add more uses of the marker under the old name (CL 241678) weren't coordinated with each other. Fixes #52612 Change-Id: I97023c0769e518491924ef457fe03bf64a2cefa6 Reviewed-on: https://go-review.googlesource.com/c/go/+/403094 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Keith Randall <khr@google.com>
2022-04-28runtime: differentiate "user" and "system" throwsMichael Pratt
"User" throws are throws due to some invariant broken by the application. "System" throws are due to some invariant broken by the runtime, environment, etc (i.e., not the fault of the application). This CL sends "user" throws through the new fatal. Currently this function is identical to throw, but with a different name to clearly differentiate the throw type in the stack trace, and hopefully be a bit more clear to users what it means. This CL changes a few categories of throw to fatal: 1. Concurrent map read/write. 2. Deadlock detection. 3. Unlock of unlocked sync.Mutex. 4. Inconsistent results from syscall.AllThreadsSyscall. "Thread exhaustion" and "out of memory" (usually address space full) throws are additional throws that are arguably the fault of user code, but I've left off for now because there is no specific invariant that they have broken to get into these states. For #51485 Change-Id: I713276a6c290fd34a6563e6e9ef378669d74ae32 Reviewed-on: https://go-review.googlesource.com/c/go/+/390420 TryBot-Result: Gopher Robot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Run-TryBot: Michael Pratt <mpratt@google.com>
2022-04-11all: gofmt main repoRuss Cox
[This CL is part of a sequence implementing the proposal #51082. The design doc is at https://go.dev/s/godocfmt-design.] Run the updated gofmt, which reformats doc comments, on the main repository. Vendored files are excluded. For #51082. Change-Id: I7332f099b60f716295fb34719c98c04eb1a85407 Reviewed-on: https://go-review.googlesource.com/c/go/+/384268 Reviewed-by: Jonathan Amsterdam <jba@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2022-04-05all: separate doc comment from //go: directivesRuss Cox
A future change to gofmt will rewrite // Doc comment. //go:foo to // Doc comment. // //go:foo Apply that change preemptively to all comments (not necessarily just doc comments). For #51082. Change-Id: Iffe0285418d1e79d34526af3520b415a12203ca9 Reviewed-on: https://go-review.googlesource.com/c/go/+/384260 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2022-04-01all: remove trailing blank doc comment linesRuss Cox
A future change to gofmt will rewrite // Doc comment. // func f() to // Doc comment. func f() Apply that change preemptively to all doc comments. For #51082. Change-Id: I4023e16cfb0729b64a8590f071cd92f17343081d Reviewed-on: https://go-review.googlesource.com/c/go/+/384259 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-12-13all: gofmt -w -r 'interface{} -> any' srcRuss Cox
And then revert the bootstrap cmd directories and certain testdata. And adjust tests as needed. Not reverting the changes in std that are bootstrapped, because some of those changes would appear in API docs, and we want to use any consistently. Instead, rewrite 'any' to 'interface{}' in cmd/dist for those directories when preparing the bootstrap copy. A few files changed as a result of running gofmt -w not because of interface{} -> any but because they hadn't been updated for the new //go:build lines. Fixes #49884. Change-Id: Ie8045cba995f65bd79c694ec77a1b3d1fe01bb09 Reviewed-on: https://go-review.googlesource.com/c/go/+/368254 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> Reviewed-by: Robert Griesemer <gri@golang.org> TryBot-Result: Gopher Robot <gobot@golang.org>
2021-11-16sync: in TryLock try to acquire mutex even if state is not 0Ian Lance Taylor
For #45435 Change-Id: I728accd9a53c1826243f52aa04dc2a0a1dfdaadf Reviewed-on: https://go-review.googlesource.com/c/go/+/363672 Trust: Ian Lance Taylor <iant@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
2021-11-11sync: clarify the validity to call Map methods inside RangeChangkun Ou
This change clarifies that calling all Map methods inside the callback of Range is allowed. For further assurance, a nested range call test is also added. Fixes #46399 Change-Id: I0a766a5c1470e6b573ec35df1ccd62b2e46f1561 Reviewed-on: https://go-review.googlesource.com/c/go/+/337389 Reviewed-by: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Ian Lance Taylor <iant@golang.org>
2021-11-06all: remove more leftover // +build linesTobias Klauser
CL 344955 and CL 359476 removed almost all // +build lines, but leaving some assembly files and generating scripts. Also, some files were added with // +build lines after CL 359476 was merged. Remove these or rename files where more appropriate. For #41184 Change-Id: I7eb85a498ed9788b42a636e775f261d755504ffa Reviewed-on: https://go-review.googlesource.com/c/go/+/361480 Trust: Tobias Klauser <tobias.klauser@gmail.com> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2021-11-04sync/atomic: disable GC during TestHammerStoreLoadMichael Anthony Knyszek
TestHammerStoreLoad involves a stress test of StorePointer, which has a write barrier. The "pointer" that is being written is not a real value, which is generally fine (though not *really* safe) on 64-bit systems because they never point to an actual object. On 32-bit systems, however, this is much more likely. Because I can't figure out how to rewrite the test such that it still is testing the same conditions but is also using real pointers, just disable the GC during the test, and make sure there isn't one currently in progress. Fixes #49362. Change-Id: If81883fedf06568132e6484f40c820aa69027a9c Reviewed-on: https://go-review.googlesource.com/c/go/+/361455 Trust: Michael Knyszek <mknyszek@google.com> Run-TryBot: Michael Knyszek <mknyszek@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org>
2021-11-01sync: add PoolStarvation benchmarkRuslan Andreev
This benchmark simulates object starvation in order to force Ps to steal objects from other Ps. Extracted from CL 314229. Change-Id: Iee31df355ba04d80fbd91c4414e397a375e6d6d7 Reviewed-on: https://go-review.googlesource.com/c/go/+/360256 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: David Chase <drchase@google.com> Trust: Cherry Mui <cherryyz@google.com>
2021-10-29sync: add Mutex.TryLock, RWMutex.TryLock, RWMutex.TryRLockRuss Cox
Use of these functions is almost (but not) always a bad idea. Very rarely they are necessary, and third-party implementations (using a mutex and an atomic word, say) cannot integrate as well with the race detector as implmentations in package sync itself. Fixes #45435. Change-Id: I0128ca48ef5e0a3b09c913f0f3a7ee5c56388000 Reviewed-on: https://go-review.googlesource.com/c/go/+/319769 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2021-10-28all: go fix -fix=buildtag std cmd (except for bootstrap deps, vendor)Russ Cox
When these packages are released as part of Go 1.18, Go 1.16 will no longer be supported, so we can remove the +build tags in these files. Ran go fix -fix=buildtag std cmd and then reverted the bootstrapDirs as defined in src/cmd/dist/buildtool.go, which need to continue to build with Go 1.4 for now. Also reverted src/vendor and src/cmd/vendor, which will need to be updated in their own repos first. Manual changes in runtime/pprof/mprof_test.go to adjust line numbers. For #41184. Change-Id: Ic0f93f7091295b6abc76ed5cd6e6746e1280861e Reviewed-on: https://go-review.googlesource.com/c/go/+/344955 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2021-10-26sync/atomic: use a better first-store-in-progress markerKeith Randall
Unlike what the comment says, the GC can see this pointer. Might as well make it a real pointer, even though ^uintptr(0) isn't currently causing problems. Removed the comment about GC not seeing the pointer. Change-Id: I04bc1fd4848698bec6afb79bd5fda671dfc9a073 Reviewed-on: https://go-review.googlesource.com/c/go/+/241661 Run-TryBot: Keith Randall <khr@golang.org> Reviewed-by: Colin Arnott <colin@urandom.co.uk> Reviewed-by: Dmitry Vyukov <dvyukov@google.com> TryBot-Result: Go Bot <gobot@golang.org> Trust: Keith Randall <khr@golang.org>
2021-10-19sync: avoid a dynamic check in WaitGroup on 64-bit architecturesCarlo Alberto Ferraris
uint64 is guaranteed by the compiler to be aligned on 64-bit archs. By using uint64+uint32 instead of [3]uint32 we can make use of the guaranteed alignment to avoid the run-time alignment check. On linux/amd64: name old time/op new time/op delta WaitGroupUncontended-4 8.84ns ± 3% 7.62ns ± 4% -13.72% (p=0.000 n=17+18) WaitGroupAddDone-4 66.8ns ± 3% 45.9ns ± 2% -31.31% (p=0.000 n=20+18) WaitGroupAddDoneWork-4 79.2ns ± 1% 56.6ns ± 1% -28.54% (p=0.000 n=17+20) WaitGroupWait-4 2.83ns ± 2% 2.58ns ± 2% -9.05% (p=0.000 n=18+20) WaitGroupWaitWork-4 16.8ns ± 6% 16.5ns ± 6% ~ (p=0.072 n=20+18) WaitGroupActuallyWait-4 263ns ± 2% 261ns ± 5% ~ (p=0.063 n=18+20) Change-Id: I314340f2ed8a47d8b9c15f8a3b07e41f252f4831 Reviewed-on: https://go-review.googlesource.com/c/go/+/189837 Reviewed-by: Cherry Mui <cherryyz@google.com> Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Cherry Mui <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-10-14sync: remove TestWaitGroupMisuse2 and TestWaitGroupMisuse3Damien Neil
These tests are inherently nondeterministic: They exercise a racy code path for up to one million iterations, and require that an error occur at least once. TestWaitGroupMisuse2 in particular is an ongoing source of trybot flakiness. Fixes #38163. Change-Id: Ibbbda2c998c915333487ad262d3df6829de01c2b Reviewed-on: https://go-review.googlesource.com/c/go/+/340249 Trust: Damien Neil <dneil@google.com> Trust: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Damien Neil <dneil@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Dmitry Vyukov <dvyukov@google.com>
2021-10-09sync: use example.com for url in ExampleWaitGroupSean Liao
Fixes #48886 Change-Id: I1093ae0ba30dab5a73d4d6bcfd083564d13877a6 Reviewed-on: https://go-review.googlesource.com/c/go/+/354830 Reviewed-by: Alberto Donizetti <alb.donizetti@gmail.com> Reviewed-by: Meng Zhuo <mzh@golangcn.org> Trust: Alberto Donizetti <alb.donizetti@gmail.com>
2021-10-07runtime,sync: using fastrandn instead of modulo reductionMeng Zhuo
fastrandn is ~50% faster than fastrand() % n. `ack -v 'fastrand\(\)\s?\%'` finds all modulo on fastrand() name old time/op new time/op delta Fastrandn/2 2.86ns ± 0% 1.59ns ± 0% -44.35% (p=0.000 n=9+10) Fastrandn/3 2.87ns ± 1% 1.59ns ± 0% -44.41% (p=0.000 n=10+9) Fastrandn/4 2.87ns ± 1% 1.58ns ± 1% -45.10% (p=0.000 n=10+10) Fastrandn/5 2.86ns ± 1% 1.58ns ± 1% -44.84% (p=0.000 n=10+10) Change-Id: Ic91f5ca9b9e3b65127bc34792b62fd64fbd13b5c Reviewed-on: https://go-review.googlesource.com/c/go/+/353269 Trust: Meng Zhuo <mzh@golangcn.org> Run-TryBot: Meng Zhuo <mzh@golangcn.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2021-08-14sync/atomic: fix documentation for CompareAndSwapJeff Wentworth
Fixes #47699 The documentation for CompareAndSwap atomic/value incorrectly labelled the function as CompareAndSwapPointer. This PR fixes that. Change-Id: I6db08fdfe166570b775248fd24550f5d28e3434e GitHub-Last-Rev: 41f78707928f48c9cdac26b6a4f618d4284e1ca1 GitHub-Pull-Request: golang/go#47700 Reviewed-on: https://go-review.googlesource.com/c/go/+/342210 Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Daniel Martí <mvdan@mvdan.cc> Trust: Daniel Martí <mvdan@mvdan.cc> Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Go Bot <gobot@golang.org>
2021-05-13all: add //go:build lines to assembly filesTobias Klauser
Don't add them to files in vendor and cmd/vendor though. These will be pulled in by updating the respective dependencies. For #41184 Change-Id: Icc57458c9b3033c347124323f33084c85b224c70 Reviewed-on: https://go-review.googlesource.com/c/go/+/319389 Trust: Tobias Klauser <tobias.klauser@gmail.com> Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Russ Cox <rsc@golang.org>
2021-05-04sync/atomic: add (*Value).Swap and (*Value).CompareAndSwapColin Arnott
The functions SwapPointer and CompareAndSwapPointer can be used to interact with unsafe.Pointer, however generally it is prefered to work with Value, due to its safer interface. As such, they have been added along with glue logic to maintain invariants Value guarantees. To meet these guarantees, the current implementation duplicates much of the Store function. Some of this is due to inexperience with concurrency and desire for correctness, but the lack of generic programming functionality does not help. Fixes #39351 Change-Id: I1aa394b1e70944736ac1e19de49fe861e1e46fba Reviewed-on: https://go-review.googlesource.com/c/go/+/241678 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org> Reviewed-by: Keith Randall <khr@golang.org>
2021-04-26Revert "sync: improve sync.Pool object stealing"Bryan C. Mills
This reverts CL 303949. Reason for revert: broke linux-arm-aws TryBots. Change-Id: Ib44949df70520cdabff857846be0d2221403d2f4 Reviewed-on: https://go-review.googlesource.com/c/go/+/313630 Trust: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Cherry Zhang <cherryyz@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-04-26sync: improve sync.Pool object stealingRuslan Andreev
This CL provide abilty to randomly select P to steal object from its shared queue. In order to provide such ability randomOrder structure was copied from runtime/proc.go. It should reduce contention in firsts Ps and improve balance of object stealing across all Ps. Also, the patch provides new benchmark PoolStarvation which force Ps to steal objects. Benchmarks: name old time/op new time/op delta Pool-8 2.16ns ±14% 2.14ns ±16% ~ (p=0.425 n=10+10) PoolOverflow-8 489ns ± 0% 489ns ± 0% ~ (p=0.719 n=9+10) PoolStarvation-8 7.00µs ± 4% 6.59µs ± 2% -5.86% (p=0.000 n=10+10) PoolSTW-8 15.1µs ± 1% 15.2µs ± 1% +0.99% (p=0.001 n=10+10) PoolExpensiveNew-8 1.25ms ±10% 1.31ms ± 9% ~ (p=0.143 n=10+10) [Geo mean] 2.68µs 2.68µs -0.28% name old p50-ns/STW new p50-ns/STW delta PoolSTW-8 15.0k ± 1% 15.1k ± 1% +0.92% (p=0.000 n=10+10) name old p95-ns/STW new p95-ns/STW delta PoolSTW-8 16.2k ± 3% 16.4k ± 2% ~ (p=0.143 n=10+10) name old GCs/op new GCs/op delta PoolExpensiveNew-8 0.29 ± 2% 0.30 ± 1% +2.84% (p=0.000 n=8+10) name old New/op new New/op delta PoolExpensiveNew-8 8.07 ±11% 8.49 ±10% ~ (p=0.123 n=10+10) Change-Id: I3ca1d0bf1f358b1148c58e64740fb2d5bfc0bc02 Reviewed-on: https://go-review.googlesource.com/c/go/+/303949 Reviewed-by: David Chase <drchase@google.com> Trust: Emmanuel Odeke <emmanuel@orijtech.com>
2021-04-08sync: update misleading comment in map.go about entry typepanchenglong01
As discussed in: https://github.com/golang/go/issues/45429, about entry type comments, it is possible for p == nil when m.dirty != nil, so update the commemt about it. Fixes #45429 Change-Id: I7ef96ee5b6948df9ac736481d177a59ab66d7d4d GitHub-Last-Rev: 202c598a0ab98f4634cb56fe2486e8e82f9d991f GitHub-Pull-Request: golang/go#45443 Reviewed-on: https://go-review.googlesource.com/c/go/+/308292 Reviewed-by: Changkun Ou <euryugasaki@gmail.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> Trust: Robert Findley <rfindley@google.com> TryBot-Result: Go Bot <gobot@golang.org>
2021-02-20all: go fmt std cmd (but revert vendor)Russ Cox
Make all our package sources use Go 1.17 gofmt format (adding //go:build lines). Part of //go:build change (#41184). See https://golang.org/design/draft-gobuild Change-Id: Ia0534360e4957e58cd9a18429c39d0e32a6addb4 Reviewed-on: https://go-review.googlesource.com/c/go/+/294430 Trust: Russ Cox <rsc@golang.org> Run-TryBot: Russ Cox <rsc@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Jason A. Donenfeld <Jason@zx2c4.com> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-11-23sync: use 386 instead of x86-32 to refer to the 32 bit x86 architectureMartin Möhrmann
This aligns the naming with GOARCH using 386 as a build target for this architecture and makes it more easily found when searching for documentation related to the build target. Change-Id: I393bb89dd2f71e568124107b13e1b288fbd0c76a Reviewed-on: https://go-review.googlesource.com/c/go/+/271988 Trust: Martin Möhrmann <moehrmann@google.com> Run-TryBot: Martin Möhrmann <martisch@uos.de> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-11-18sync: document RWMutex race semanticsMichael Pratt
RWMutex provides explicit acquire/release synchronization events to the race detector to model the mutex. It disables sync events within the methods to avoid e.g., the atomics from adding false synchronization events, which could cause false negatives in the race detector. Change-Id: I5126ce2efaab151811ac264864aab1fa025a4aaf Reviewed-on: https://go-review.googlesource.com/c/go/+/270865 Run-TryBot: Michael Pratt <mpratt@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Austin Clements <austin@google.com> Trust: Michael Pratt <mpratt@google.com>
2020-10-26cmd/go,cmd/compile,sync: remove special import case in cmd/goAustin Clements
CL 253748 introduced a special case in cmd/go to allow sync to import runtime/internal/atomic. Besides introducing unnecessary complexity into cmd/go, this breaks other packages (like gopls) that understand how imports work, but don't understand this special case. Fix this by using the more standard linkname-based approach to pull the necessary functions from runtime/internal/atomic into sync. Since these are compiler intrinsics, we also have to tell the compiler that the linknamed symbols are intrinsics to get this optimization in sync. Fixes #42196. Change-Id: I1f91498c255c91583950886a89c3c9adc39a32f0 Reviewed-on: https://go-review.googlesource.com/c/go/+/265124 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> Reviewed-by: Bryan C. Mills <bcmills@google.com> Reviewed-by: Keith Randall <khr@golang.org> Reviewed-by: Paul Murphy <murp@ibm.com> TryBot-Result: Go Bot <gobot@golang.org>
2020-10-23sync: document that Once must not be copiedDmitri Shuralyov
Fixes #42160. Change-Id: I9bf8b6f0bf1eccd3ab32cbd94c812f768746d291 Reviewed-on: https://go-review.googlesource.com/c/go/+/264557 Trust: Dmitri Shuralyov <dmitshur@golang.org> Run-TryBot: Dmitri Shuralyov <dmitshur@golang.org> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2020-10-21cmd/compiler,cmd/go,sync: add internal {LoadAcq,StoreRel}64 on ppc64Paul E. Murphy
Add an internal atomic intrinsic for load with acquire semantics (extending LoadAcq to 64b) and add LoadAcquintptr for internal use within the sync package. For other arches, this remaps to the appropriate atomic.Load{,64} intrinsic which should not alter code generation. Similarly, add StoreRel{uintptr,64} for consistency, and inline. Finally, add an exception to allow sync to directly use the runtime/internal/atomic package which avoids more convoluted workarounds (contributed by Lynn Boger). In an extreme example, sync.(*Pool).pin consumes 20% of wall time during fmt tests. This is reduced to 5% on ppc64le/power9. From the fmt benchmarks on ppc64le: name old time/op new time/op delta SprintfPadding 468ns ± 0% 451ns ± 0% -3.63% SprintfEmpty 73.3ns ± 0% 51.9ns ± 0% -29.20% SprintfString 135ns ± 0% 122ns ± 0% -9.63% SprintfTruncateString 232ns ± 0% 214ns ± 0% -7.76% SprintfTruncateBytes 216ns ± 0% 202ns ± 0% -6.48% SprintfSlowParsingPath 162ns ± 0% 142ns ± 0% -12.35% SprintfQuoteString 1.00µs ± 0% 0.99µs ± 0% -1.39% SprintfInt 117ns ± 0% 104ns ± 0% -11.11% SprintfIntInt 190ns ± 0% 175ns ± 0% -7.89% SprintfPrefixedInt 232ns ± 0% 212ns ± 0% -8.62% SprintfFloat 270ns ± 0% 255ns ± 0% -5.56% SprintfComplex 1.01µs ± 0% 0.99µs ± 0% -1.68% SprintfBoolean 127ns ± 0% 111ns ± 0% -12.60% SprintfHexString 220ns ± 0% 198ns ± 0% -10.00% SprintfHexBytes 261ns ± 0% 252ns ± 0% -3.45% SprintfBytes 600ns ± 0% 590ns ± 0% -1.67% SprintfStringer 684ns ± 0% 658ns ± 0% -3.80% SprintfStructure 2.57µs ± 0% 2.57µs ± 0% -0.12% ManyArgs 669ns ± 0% 646ns ± 0% -3.44% FprintInt 140ns ± 0% 136ns ± 0% -2.86% FprintfBytes 184ns ± 0% 181ns ± 0% -1.63% FprintIntNoAlloc 140ns ± 0% 136ns ± 0% -2.86% ScanInts 929µs ± 0% 921µs ± 0% -0.79% ScanRecursiveInt 122ms ± 0% 121ms ± 0% -0.11% ScanRecursiveIntReaderWrapper 122ms ± 0% 122ms ± 0% -0.18% Change-Id: I4d66780261b57b06ef600229e475462e7313f0d6 Reviewed-on: https://go-review.googlesource.com/c/go/+/253748 Run-TryBot: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Lynn Boger <laboger@linux.vnet.ibm.com> Reviewed-by: Keith Randall <khr@golang.org> Trust: Lynn Boger <laboger@linux.vnet.ibm.com> TryBot-Result: Go Bot <gobot@golang.org>
2020-10-16runtime/internal/atomic: panic nicely on unaligned 64-bit atomicsAustin Clements
On 386 and arm, unaligned 64-bit atomics aren't safe, so we check for this and panic. Currently, we panic by dereferencing nil, which may be expedient but is pretty user-hostile since it gives no hint of what the actual problem was. This CL replaces this with an actual panic. The only subtlety here is now the atomic assembly implementations are calling back into Go, so they have to play nicely with stack maps and stack scanning. On 386, this just requires declaring NO_LOCAL_POINTERS. On arm, this is somewhat more complicated: first, we have to move the alignment check into the functions that have Go signatures. Then we have to support both the tail call from these functions to the underlying implementation (which requires that they have no frame) and the call into Go to panic (which requires that they have a frame). We resolve this by forcing them to have no frame and setting up the frame manually just before the panic call. Change-Id: I19f1e860045df64088013db37a18acea47342c69 Reviewed-on: https://go-review.googlesource.com/c/go/+/262778 Trust: Austin Clements <austin@google.com> Run-TryBot: Austin Clements <austin@google.com> TryBot-Result: Go Bot <gobot@golang.org> Reviewed-by: Cherry Zhang <cherryyz@google.com> Reviewed-by: Michael Knyszek <mknyszek@google.com>
2020-10-14sync: fix typo in pooldequeueZhangYunHao
. Change-Id: I26fa26d67d01bcd583a1efaaf9a38398cbf793f7 GitHub-Last-Rev: ded020d02ca2e429f7c31065e5a27dae6eb7a611 GitHub-Pull-Request: golang/go#41932 Reviewed-on: https://go-review.googlesource.com/c/go/+/261477 Trust: Alberto Donizetti <alb.donizetti@gmail.com> Reviewed-by: Austin Clements <austin@google.com>
2020-08-24sync: delete dirty keys inside Map.LoadAndDeleteChangkun Ou
Fixes #40999 Change-Id: Ie32427e5cb5ed512b976b554850f50be156ce9f2 Reviewed-on: https://go-review.googlesource.com/c/go/+/250197 Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2020-08-17all: add empty line between copyright header and package clauseTobias Klauser
Makes sure the copyright notice is not interpreted as the package level godoc. Change-Id: I2afce7c9d620f19d51ec1438b1d0db1774b57146 Reviewed-on: https://go-review.googlesource.com/c/go/+/248760 Run-TryBot: Tobias Klauser <tobias.klauser@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Dave Cheney <dave@cheney.net>
2020-08-14sync: fix goroutine leak for when TestMutexFairness times outGaurav Singh
If the timeout triggers before writing to the done channel, the goroutine will be blocked waiting for a corresponding read that’s no longer existent, thus a goroutine leak. This change fixes that by using a buffered channel instead. Change-Id: I9cf4067a58bc5a729ab31e4426edd78bd359e8e0 GitHub-Last-Rev: a7d811a7be6d875175a894e53d474aa0034e7d2c GitHub-Pull-Request: golang/go#40236 Reviewed-on: https://go-review.googlesource.com/c/go/+/242902 Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-07-25runtime, sync: add copyright headers to new filesIan Lance Taylor
For #38029 Change-Id: I71de2b66c1de617d32c46d4f2c1866f9ff1756ec Reviewed-on: https://go-review.googlesource.com/c/go/+/244631 Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Dan Scales <danscales@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-04-08net/textproto, sync: unlock mutexes appropriately before panicsBurtonQin
Ensure mutexes are unlocked right before panics, where defers aren’t easily usable. Change-Id: I67c9870e7a626f590a8de8df6c8341c5483918dc GitHub-Last-Rev: bb8ffe538b3956892b55884fd64eadfce326f7b0 GitHub-Pull-Request: golang/go#37143 Reviewed-on: https://go-review.googlesource.com/c/go/+/218717 Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com> Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-04-07runtime: static lock ranking for the runtime (enabled by GOEXPERIMENT)Dan Scales
I took some of the infrastructure from Austin's lock logging CR https://go-review.googlesource.com/c/go/+/192704 (with deadlock detection from the logs), and developed a setup to give static lock ranking for runtime locks. Static lock ranking establishes a documented total ordering among locks, and then reports an error if the total order is violated. This can happen if a deadlock happens (by acquiring a sequence of locks in different orders), or if just one side of a possible deadlock happens. Lock ordering deadlocks cannot happen as long as the lock ordering is followed. Along the way, I found a deadlock involving the new timer code, which Ian fixed via https://go-review.googlesource.com/c/go/+/207348, as well as two other potential deadlocks. See the constants at the top of runtime/lockrank.go to show the static lock ranking that I ended up with, along with some comments. This is great documentation of the current intended lock ordering when acquiring multiple locks in the runtime. I also added an array lockPartialOrder[] which shows and enforces the current partial ordering among locks (which is embedded within the total ordering). This is more specific about the dependencies among locks. I don't try to check the ranking within a lock class with multiple locks that can be acquired at the same time (i.e. check the ranking when multiple hchan locks are acquired). Currently, I am doing a lockInit() call to set the lock rank of most locks. Any lock that is not otherwise initialized is assumed to be a leaf lock (a very high rank lock), so that eliminates the need to do anything for a bunch of locks (including all architecture-dependent locks). For two locks, root.lock and notifyList.lock (only in the runtime/sema.go file), it is not as easy to do lock initialization, so instead, I am passing the lock rank with the lock calls. For Windows compilation, I needed to increase the StackGuard size from 896 to 928 because of the new lock-rank checking functions. Checking of the static lock ranking is enabled by setting GOEXPERIMENT=staticlockranking before doing a run. To make sure that the static lock ranking code has no overhead in memory or CPU when not enabled by GOEXPERIMENT, I changed 'go build/install' so that it defines a build tag (with the same name) whenever any experiment has been baked into the toolchain (by checking Expstring()). This allows me to avoid increasing the size of the 'mutex' type when static lock ranking is not enabled. Fixes #38029 Change-Id: I154217ff307c47051f8dae9c2a03b53081acd83a Reviewed-on: https://go-review.googlesource.com/c/go/+/207619 Reviewed-by: Dan Scales <danscales@google.com> Reviewed-by: Keith Randall <khr@golang.org> Run-TryBot: Dan Scales <danscales@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2020-04-02sync/atomic: fix TestSwapPointer testKeith Randall
It plays way too loose with unsafe.Pointer rules. It runs afoul of the checkptr rules, so some race detector builds were failing. Fixes #38210 Change-Id: I5e1c78201d06295524fdedb3fe5b49d61446f443 Reviewed-on: https://go-review.googlesource.com/c/go/+/226880 Run-TryBot: Keith Randall <khr@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Josh Bleecher Snyder <josharian@gmail.com>
2020-03-19sync/atomic: remove panic64Daniel Martí
The func has been unused since https://golang.org/cl/93637 in 2018. Change-Id: I1cab6f265aa5058ac080fd7c7cbf0fe85370f073 Reviewed-on: https://go-review.googlesource.com/c/go/+/224077 Run-TryBot: Daniel Martí <mvdan@mvdan.cc> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Matt Layher <mdlayher@gmail.com> Reviewed-by: Austin Clements <austin@google.com>
2020-02-27all: fix incorrect channel and API usage in some unit testsZiheng Liu
This CL changes some unit test functions, making sure that these tests (and goroutines spawned during test) won't block. Since they are just test functions, I use one CL to fix them all. I hope this won't cause trouble to reviewers and can save time for us. There are three main categories of incorrect logic fixed by this CL: 1. Use testing.Fatal()/Fatalf() in spawned goroutines, which is forbidden by Go's document. 2. Channels are used in such a way that, when errors or timeout happen, the test will be blocked and never return. 3. Channels are used in such a way that, when errors or timeout happen, the test can return but some spawned goroutines will be leaked, occupying resource until all other tests return and the process is killed. Change-Id: I3df931ec380794a0cf1404e632c1dd57c65d63e8 Reviewed-on: https://go-review.googlesource.com/c/go/+/219380 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Ian Lance Taylor <iant@golang.org>
2020-02-25sync: add new Map method LoadAndDeleteChangkun Ou
This CL implements a LoadAndDelete method in sync.Map. Benchmark: name time/op LoadAndDeleteBalanced/*sync_test.RWMutexMap-12 98.8ns ± 1% LoadAndDeleteBalanced/*sync.Map-12 10.3ns ±11% LoadAndDeleteUnique/*sync_test.RWMutexMap-12 99.2ns ± 2% LoadAndDeleteUnique/*sync.Map-12 6.63ns ±10% LoadAndDeleteCollision/*sync_test.DeepCopyMap-12 140ns ± 0% LoadAndDeleteCollision/*sync_test.RWMutexMap-12 75.2ns ± 2% LoadAndDeleteCollision/*sync.Map-12 5.21ns ± 5% In addition, Delete is bounded and more efficient if many collisions: DeleteCollision/*sync_test.DeepCopyMap-12 120ns ± 2% 125ns ± 1% +3.80% (p=0.000 n=10+9) DeleteCollision/*sync_test.RWMutexMap-12 73.5ns ± 3% 79.5ns ± 1% +8.03% (p=0.000 n=10+9) DeleteCollision/*sync.Map-12 97.8ns ± 3% 5.9ns ± 4% -94.00% (p=0.000 n=10+10) Fixes #33762 Change-Id: Ic8469a7861d27ab0edeface0078aad8af9b26c2f Reviewed-on: https://go-review.googlesource.com/c/go/+/205899 Reviewed-by: Bryan C. Mills <bcmills@google.com> Run-TryBot: Bryan C. Mills <bcmills@google.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
2019-12-06sync: deflake TestWaitGroupMisuse3Ian Lance Taylor
If one of the helper goroutine panics, the main goroutine call to Wait may hang forever waiting for something to call Done. Put that call in a goroutine like the others. Fixes #35774 Change-Id: I8d2b58d8f473644a49a95338f70111d4e6ed4e12 Reviewed-on: https://go-review.googlesource.com/c/go/+/210218 Run-TryBot: Ian Lance Taylor <iant@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Bryan C. Mills <bcmills@google.com>
2019-11-09sync: yield to the waiter when unlocking a starving mutexRhys Hiltner
When we have already assigned the semaphore ticket to a specific waiter, we want to get the waiter running as fast as possible since no other G waiting on the semaphore can acquire it optimistically. The net effect is that, when a sync.Mutex is contended, the code in the critical section guarded by the Mutex gets a priority boost. Fixes #33747 The original work was done in CL 200577 by Carlo Alberto Ferraris. The change was reverted in CL 205817 because it broke the linux-arm64-packet and solaris-amd64-oraclerel builders. Change-Id: I76d79b1d63fd206ed1c57fe6900cb7ae9e4d46cb Reviewed-on: https://go-review.googlesource.com/c/go/+/206180 Run-TryBot: Brad Fitzpatrick <bradfitz@golang.org> TryBot-Result: Gobot Gobot <gobot@golang.org> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-11-07Revert "sync: yield to the waiter when unlocking a starving mutex"Bryan C. Mills
This reverts CL 200577. Reason for revert: broke linux-arm64-packet and solaris-amd64-oraclerel builders Fixes #35424 Updates #33747 Change-Id: I2575fd84d37995d458183caae54704f15d8b8426 Reviewed-on: https://go-review.googlesource.com/c/go/+/205817 Run-TryBot: Bryan C. Mills <bcmills@google.com> Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
2019-11-07sync: yield to the waiter when unlocking a starving mutexCarlo Alberto Ferraris
When we have already assigned the semaphore ticket to a specific waiter, we want to get the waiter running as fast as possible since no other G waiting on the semaphore can acquire it optimistically. The net effect is that, when a sync.Mutex is contented, the code in the critical section guarded by the Mutex gets a priority boost. Fixes #33747 Change-Id: I9967f0f763c25504010651bdd7f944ee0189cd45 Reviewed-on: https://go-review.googlesource.com/c/go/+/200577 Reviewed-by: Rhys Hiltner <rhys@justin.tv> Reviewed-by: Ian Lance Taylor <iant@golang.org> Run-TryBot: Emmanuel Odeke <emm.odeke@gmail.com> TryBot-Result: Gobot Gobot <gobot@golang.org>
generated by cgit v1.3 (git 2.53.0) at 2026-04-15 15:05:23 +0000