Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

runtime: non-blocking read on an empty closed channel takes the slow path #32529

Closed
bemasc opened this issue Jun 10, 2019 · 5 comments
Closed

runtime: non-blocking read on an empty closed channel takes the slow path #32529

bemasc opened this issue Jun 10, 2019 · 5 comments

Comments

@bemasc
Copy link
Contributor

@bemasc bemasc commented Jun 10, 2019

On my workstation, nonblocking receive on an empty open channel is about 700 times faster than nonblocking receive on an empty closed channel. This is because chanrecv() in runtime/chan.go has a special-case optimization that takes a lock-free path in this case. A similar lock-free path can be implemented for closed channels, and should result in similar performance.

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jun 10, 2019

Change https://golang.org/cl/181543 mentions this issue: runtime: Faster receive on a closed channels

@ALTree ALTree changed the title runtime: Non-blocking read on an empty closed channel takes the slow path runtime: non-blocking read on an empty closed channel takes the slow path Jun 10, 2019
@ALTree ALTree added the Performance label Jun 10, 2019
@ALTree ALTree added this to the Unplanned milestone Jun 10, 2019
@gopherbot gopherbot closed this in e1446d9 Oct 7, 2019
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jan 23, 2020

Change https://golang.org/cl/216158 mentions this issue: Revert "runtime: speed up receive on empty closed channel"

@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jan 23, 2020

Change https://golang.org/cl/216099 mentions this issue: runtime/race: add test case for #36714

@randall77 randall77 reopened this Jan 24, 2020
@randall77

This comment has been minimized.

Copy link
Contributor

@randall77 randall77 commented Jan 24, 2020

Reopened because fixing CL has been reverted.

gopherbot pushed a commit that referenced this issue Jan 24, 2020
This reverts CL 181543 (git e1446d9)

Reason for revert: Caused a regression in the race detector.

Updates #32529
Fixes #36714

Change-Id: Ifefe6784f86ea72f414a89f131c239e9c9fd74eb
Reviewed-on: https://go-review.googlesource.com/c/go/+/216158
Run-TryBot: Alexander Rakoczy <alex@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
Reviewed-by: Austin Clements <austin@google.com>
Reviewed-by: Ian Lance Taylor <iant@golang.org>
@gopherbot

This comment has been minimized.

Copy link

@gopherbot gopherbot commented Jan 29, 2020

Change https://golang.org/cl/216818 mentions this issue: runtime: speed up receive on empty closed channel

gopherbot pushed a commit that referenced this issue Mar 20, 2020
Add a test to ensure that the race detector sees that closing a
channel synchronizes with a read from that channel.
This test case failed when CL 181543 was in the tree.
CL 181543 was reverted in CL 216158; this adds a test to make
sure that we don't re-introduce the problem at a later date.

For #32529
For #36714

Change-Id: I5a40f744c67c3f8191d6ad822710c180880a7375
Reviewed-on: https://go-review.googlesource.com/c/go/+/216099
Run-TryBot: Ian Lance Taylor <iant@golang.org>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Emmanuel Odeke <emm.odeke@gmail.com>
@gopherbot gopherbot closed this in 02e492f Mar 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
5 participants
You can’t perform that action at this time.