Skip to content

sync/atomic: TestStoreLoadSeqCst/RelAcq take a bit long time on freebsd/386 #3226

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
Closed
mikioh opened this issue Mar 7, 2012 · 5 comments
Closed

sync/atomic: TestStoreLoadSeqCst/RelAcq take a bit long time on freebsd/386 #3226

mikioh opened this issue Mar 7, 2012 · 5 comments
Labels
FrozenDueToAge

Comments

@mikioh
Copy link
Contributor

mikioh commented Mar 7, 2012 

What steps will reproduce the problem?
1. go test -v sync/atomic
2.
3.

What is the expected output? What do you see instead?
=== RUN TestHammer32
--- PASS: TestHammer32 (0.03 seconds)
=== RUN TestHammer64
--- PASS: TestHammer64 (0.02 seconds)
=== RUN TestHammerStoreLoad
--- PASS: TestHammerStoreLoad (0.95 seconds)
=== RUN TestStoreLoadSeqCst32
--- PASS: TestStoreLoadSeqCst32 (131.83 seconds)
=== RUN TestStoreLoadSeqCst64
--- PASS: TestStoreLoadSeqCst64 (133.62 seconds)
=== RUN TestStoreLoadRelAcq32
--- PASS: TestStoreLoadRelAcq32 (132.61 seconds)
=== RUN TestStoreLoadRelAcq64
--- PASS: TestStoreLoadRelAcq64 (132.73 seconds)
PASS

Please use labels and text to provide additional information.
% go version
go version weekly.2012-03-04 +f4470a54e6db
@rsc
Copy link
Contributor

rsc commented Mar 7, 2012

Comment 1:

Is this a single-processor machine?
Perhaps FreeBSD/386's runtime does not implement osyield?

@mikioh
Copy link
Contributor Author

mikioh commented Mar 7, 2012

Comment 2:

It's a single-processor assigned VM running on VMware.
I don't think so, Devon implemented it a few weeks ago.
<http://golang.org/cl/5689046>;

@rsc
Copy link
Contributor

rsc commented Mar 7, 2012

Comment 3:

It's a useless test on a single-processor.
Now that we have the function, we should just
disable this test when runtime.NumCPU() == 1.

@mikioh
Copy link
Contributor Author

mikioh commented Mar 7, 2012

Comment 4:

Ack, let it get disabled.

@mikioh
Copy link
Contributor Author

mikioh commented Mar 7, 2012

Comment 5:

This issue was closed by revision e2b207b.

Status changed to Fixed.

@golang golang locked and limited conversation to collaborators Jun 24, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@mikioh @rsc @gopherbot