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

sync/atomic: FreeBSD/ARM Load* Store* implementations missing memory barriers #23778

Closed
paulzhol opened this issue Feb 11, 2018 · 9 comments
Closed
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-FreeBSD
Milestone

Comments

@paulzhol
Copy link
Member

TEXT ·LoadUint32(SB),NOSPLIT,$0-8
MOVW addr+0(FP), R1
load32loop:
LDREX (R1), R2 // loads R2
STREX R2, (R1), R0 // stores R2
CMP $0, R0
BNE load32loop
MOVW R2, val+4(FP)
RET

The runtime/internal/atomic version is using memory barriers correctly in the underlying armcas:

TEXT runtime∕internal∕atomic·armcas(SB),NOSPLIT,$0-13
MOVW ptr+0(FP), R1
MOVW old+4(FP), R2
MOVW new+8(FP), R3
casl:
LDREX (R1), R0
CMP R0, R2
BNE casfail
MOVB runtime·goarm(SB), R11
CMP $7, R11
BLT 2(PC)
WORD $0xf57ff05a // dmb ishst
STREX R3, (R1), R0
CMP $0, R0
BNE casl
MOVW $1, R0
MOVB runtime·goarm(SB), R11
CMP $7, R11
BLT 2(PC)
WORD $0xf57ff05b // dmb ish
MOVB R0, ret+12(FP)
RET
casfail:
MOVW $0, R0
MOVB R0, ret+12(FP)
RET

@paulzhol paulzhol changed the title sync/atomic: Load* Store* implementations missing memory barriers sync/atomic: FreeBSD/ARM Load* Store* implementations missing memory barriers Feb 11, 2018
@ianlancetaylor ianlancetaylor added this to the Go1.11 milestone Feb 11, 2018
@ianlancetaylor ianlancetaylor added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Feb 11, 2018
@ianlancetaylor
Copy link
Contributor

CC @cherrymui

@bcmills
Copy link
Contributor

bcmills commented Feb 12, 2018

I'm probably missing something, but why do we have so many GOOS variations for atomic.{Load,Store}Uint32 in the first place?

(I understand why we have one for Linux — because it provides a built-in implementation — but why shouldn't the fallback implementation be the same for every other OS?)

@randall77
Copy link
Contributor

@bcmills The fallback implementation is the same for all the other OSes.
(e.g. sys_netbsd_arm.s just redirects to asm_arm.s)

@gopherbot
Copy link

Change https://golang.org/cl/93615 mentions this issue: runtime/internal/atomic, sync/atomic: unify memory barrier macros

@bcmills
Copy link
Contributor

bcmills commented Feb 13, 2018

The fallback implementation is the same for all the other OSes.

That seems to be true for most of the functions, but not atomic.{Load,Store}Uint32:

TEXT ·LoadUint32(SB),NOSPLIT,$0-8
MOVW addr+0(FP), R1
load32loop:
LDREX (R1), R2 // loads R2
STREX R2, (R1), R0 // stores R2
CMP $0, R0
BNE load32loop
MOVW R2, val+4(FP)
RET

...or am I missing something more subtle to it?

@gopherbot
Copy link

Change https://golang.org/cl/93635 mentions this issue: runtime/internal/atomic: unify sys_*_arm.s on non-linux

@gopherbot
Copy link

Change https://golang.org/cl/93637 mentions this issue: sync/atomic: redirect many functions to runtime/internal/atomic

@randall77
Copy link
Contributor

@bcmills Sorry, you are right. I was looking at runtime/internal/atomic, not sync/atomic.

@cherrymui
Copy link
Member

@bcmills I don't see a good reason not to unify those.

gopherbot pushed a commit that referenced this issue Feb 14, 2018
Updates #23778.

Change-Id: I80e57a15b6e3bbc2e25ea186399ff0e360fc5c21
Reviewed-on: https://go-review.googlesource.com/93635
Run-TryBot: Cherry Zhang <cherryyz@google.com>
TryBot-Result: Gobot Gobot <gobot@golang.org>
Reviewed-by: Austin Clements <austin@google.com>
@golang golang locked and limited conversation to collaborators May 3, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
FrozenDueToAge NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. OS-FreeBSD
Projects
None yet
Development

No branches or pull requests

6 participants