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.

Sign up for GitHub

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

Jump to bottom

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
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Milestone
Unplanned

Comments

@bemasc
Copy link
Contributor

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
Copy link

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 this to the Unplanned milestone Jun 10, 2019
@FiloSottile FiloSottile added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jun 14, 2019
@gopherbot
Copy link

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

@gopherbot
Copy link

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

@randall77 randall77 reopened this Jan 24, 2020
@randall77
Copy link
Contributor

Reopened because fixing CL has been reverted.

gopherbot pushed a commit that referenced this issue Jan 24, 2020
@toothrot
Revert "runtime: speed up receive on empty closed channel"
e35876e 
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
Copy link

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
@ianlancetaylor
runtime/race: test that close synchronizes with read
635a830 
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>
@golang golang locked and limited conversation to collaborators Mar 22, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. Performance
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@bemasc @FiloSottile @ALTree @randall77 @gopherbot