¿ Where is the source code of atomic.AddInt32?

[Victor Giordano]

Hi there! 

Hope you are having a great weekend (This is actually friendly greeting and you may greet me as well, it will be more than welcome)

 I reach this line and that is folks!

I was expetecting to find something like

mutex.Lock()

(*intParam)++

mutex.Unlock()

Can anyone give a little insight of this. If the burden of what is happening implies to assambly code I will be satisfied with any shallow explanation. If the first time I saw code in golang that reseembles the code in Java prefixed with native keyword.

Thanks!

[Ian Lance Taylor]

On Sun, Apr 23, 2023 at 12:23 PM Victor Giordano <vituc...@gmail.com> wrote:

Hi there! 

Hope you are having a great weekend (This is actually friendly greeting and you may greet me as well, it will be more than welcome)

 I reach this line and that is folks!

I was expetecting to find something like

mutex.Lock()

(*intParam)++

mutex.Unlock()

Can anyone give a little insight of this. If the burden of what is happening implies to assambly code I will be satisfied with any shallow explanation. If the first time I saw code in golang that reseembles the code in Java prefixed with native keyword.

The implementation is written in assembler, in the file asm.s.  In the current implementation it just jumps to the implementation in the runtime/internal/atomic package.  In that package, for most targets, look at the atomic_GOARCH.s file.

It's not normally implemented using a mutex, it's normally implemented using processor-specific atomic instructions.

And I'll add that actually the implementation in runtime/internal/atomic isn't normally used, normally the function is implemented directly by the compiler.

Ian

[Eli Lindsey]

Hi Victor,

This shows that the code you linked is a shim over runtime/internal/atomic: https://cs.opensource.google/go/go/+/refs/tags/go1.20.3:src/sync/atomic/asm.s;l=40

In runtime/internal/atomic you’ll find asm implementations specific to the various supported architectures. For example, here is the implementation for x86_64: https://cs.opensource.google/go/go/+/refs/tags/go1.20.3:src/runtime/internal/atomic/atomic_amd64.s;l=83

If the burden of what is happening implies to assambly code I will be satisfied with any shallow explanation.

What the assembly does will vary by architecture, so it depends on which one you’re interested in. 

Many arches have built-in support for atomics, so the asm will look like a regular exchange-and-add with some additional prefix to say “do this atomically” (eg. on the above x86-64 this is LOCK XADD, https://www.felixcloutier.com/x86/xadd).

aarch64/arm64 is a good example of how this may vary though - https://cs.opensource.google/go/go/+/refs/tags/go1.20.3:src/runtime/internal/atomic/atomic_arm64.s;l=228

In this case it’s detecting if atomics are supported and using them if so (LDADD, similar to x86’s LOCK XADD). But not all arm64 revisions support atomic arithmetic, so if unavailable it falls back to a load/add/store loop, retrying the add until it succeeds without conflict.

-eli

--
You received this message because you are subscribed to the Google Groups "golang-nuts" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/c4c2a754-b282-4905-9cbe-19fe8f5355a6n%40googlegroups.com.