Done with:
go get go@1.18
go mod tidy
go fix ./...
Using go1.21.3.
While here, simplify package syncmap by taking advantage of knowing
that all supported Go versions will have the go1.9 build constraint
satisfied.
For golang/go#60268.
Change-Id: Ic0f24ab13ada6839573e55beee5516c1a6c7f3cc
Reviewed-on: https://go-review.googlesource.com/c/sync/+/534220
Auto-Submit: Dmitri Shuralyov <dmitshur@golang.org>
Reviewed-by: Ian Lance Taylor <iant@google.com>
LUCI-TryBot-Result: Go LUCI <golang-scoped@luci-project-accounts.iam.gserviceaccount.com>
Reviewed-by: Dmitri Shuralyov <dmitshur@google.com>
Make all our package sources use Go 1.17 gofmt format
(adding //go:build lines).
Not strictly necessary but will avoid spurious changes
as files are edited.
Part of //go:build change (#41184).
See https://golang.org/design/draft-gobuild
Change-Id: Ie3f0a5f80ab53b95a25db9ccfd9a3cc4ea7ff465
Reviewed-on: https://go-review.googlesource.com/c/sync/+/294370
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: Robert Griesemer <gri@golang.org>
When `Release`, if the remaining tokens are not enough for the front waiter, no waiters will be notified.
So if the canceled waiter is the front one, it should try to notify following waiters if there are remaining tokens.
I found this bug when implementing a cancelable rwmutex based on semaphore:
https://github.com/zhiqiangxu/util/blob/master/mutex/crwmutex.go
This bug can be verified by this test:
https://github.com/zhiqiangxu/util/blob/master/mutex/crwmutex_test.go#L43
Change-Id: Id8564976bd375a82c4fbc6cb08b0bb83118a346c
GitHub-Last-Rev: 29b6ff26bf779d23239cfe64a395378a9e41d1fc
GitHub-Pull-Request: golang/sync#10
Reviewed-on: https://go-review.googlesource.com/c/sync/+/223418
Run-TryBot: Bryan C. Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Bryan C. Mills <bcmills@google.com>
I've commented several times in various forums that basically every
time I've seen the “worker goroutine” pattern in Go, there has turned
out to be a cleaner implementation using semaphores.
This change adds a simple such example. (For more complex usage, I
would generally pair the semaphore with an errgroup.Group.)
Change-Id: Ibf69ee761d14ba59c1acc6a2d595b4fcf0d8f6d6
Reviewed-on: https://go-review.googlesource.com/75170
Reviewed-by: Ross Light <light@google.com>
TestWeighted's runtime was roughly proportional to the number of CPUs,
so it ran a long time on PPCs (160 CPUs).
Make the number of loops in the test an inverse function of the number
of CPUs, to keep the test short.
Change-Id: Id853dbb5e5e2f9fb95966d19ef0c511e3f8080e0
Reviewed-on: https://go-review.googlesource.com/43632
Reviewed-by: Bryan Mills <bcmills@google.com>
Run-TryBot: Bryan Mills <bcmills@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
This package provides a weighted semaphore that is context-aware.
The code is derived from a similar package inside Google.
Change-Id: Id1dad96d79e8ccfd289e4299e8265aa5bdad3a5b
Reviewed-on: https://go-review.googlesource.com/38298
Reviewed-by: Ian Lance Taylor <iant@golang.org>
Reviewed-by: Damien Neil <dneil@google.com>
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
