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

Go: don't use the sync/atomic package unless absolutely necessary #1688

Closed
kormat opened this issue Jul 18, 2018 · 4 comments
Closed

Go: don't use the sync/atomic package unless absolutely necessary #1688

kormat opened this issue Jul 18, 2018 · 4 comments
Labels
bug Something isn't working

Comments

@kormat
Copy link
Contributor

kormat commented Jul 18, 2018

It turns out there's an alignment "bug" that triggers when you use sync/atomic on structures that aren't aligned according to the platform rules.

https://golang.org/pkg/sync/atomic/#pkg-note-BUG
golang/go#599

This causes subtle cross-platform bugs, and is not worth the complexity for non-critical paths.

kormat pushed a commit that referenced this issue Jul 18, 2018
Fixes some issues where 64-bit assumptions in the code cause problems on a 32-bit platform.

N.B.: There is a problem with the alignment of the sciond.connector struct in Go on ARM 32 that this does _not_ fix. #1688 is filed to track a higher-level fix for this issue.
@lukedirtwalker
Copy link
Collaborator

There is now a vet pass called atomicalign that should detect those issues. We should use that.
(see golang/go#11891 (comment))
(see https://godoc.org/golang.org/x/tools/go/analysis/passes/atomicalign)

@kormat
Copy link
Contributor Author

kormat commented Jun 3, 2019

@lukedirtwalker : In that case we'd want to have automated testing on at least arm, otherwise we won't know when it breaks.

@kormat
Copy link
Contributor Author

kormat commented Jun 3, 2019

Oh, even worse - bazel doesn't support arm as a host platform, so we can't actually build on an arm vm => can't do automated testing.

@scrye scrye added the bug Something isn't working label May 5, 2020
@scrye
Copy link
Contributor

scrye commented Jan 5, 2021

Closing as unactionable. However, note that we have 0 uses of sync/atomic in the code base at the moment, so it looks like this is already avoided by us never needing such low-level concurrency optimization primitives.

@scrye scrye closed this as completed Jan 5, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants