proposal: sync/atomic: add logical operations

[bartoszmodelski2]

x86, x64 support atomic instructions for NOT, AND, OR, XOR. I believe, exposing them has some advantages:

• higher performance than Load&CompAndSwap
• cleaner code
• it also reduces the risk of contention in some applications, hence increased stability

As for other architectures, implementing these operations in assembly should yield some considerable speed-up and said cleaner code.

Example application: bloom filters.

Example AND/OR implementations for int64, amd64:

//declarations.go
//go:noescape
func And(ptr *int64, delta int64)

//go:noescape
func Or(ptr *int64, delta int64)

//operations.s
#include "textflag.h"

TEXT ·Or(SB), NOSPLIT, $0-16
	MOVQ	ptr+0(FP), BX       
	MOVQ	delta+8(FP), AX    
	LOCK	
   	ORQ	AX, 0(BX)               

	RET

TEXT ·And(SB), NOSPLIT, $0-16
	MOVQ	ptr+0(FP), BX     
	MOVQ	delta+8(FP), AX    

    	LOCK	
    	ANDQ	AX, 0(BX)           

	RET

[ianlancetaylor]

Do any non-x86 processors support these operations?

How often do they really come up in practice? What existing code could be simplified by using these operations?

[randall77]

One data point: we use Or8 inside the runtime. It's defined in runtime/internal/atomic.
It is in assembly except for arm (which uses a compare-and-swap) and wasm (which punts on the whole atomic thing for now).

[beoran]

While this is useful, I think this would best be made into a third party library, unless if the Go compiler itself could be optimized with this somehow.

[bartoszmodelski2]

Do any non-x86 processors support these operations?

No

How often do they really come up in practice? What existing code could be simplified by using these operations?

Any data structure with flags changing a lot. RWMutex means a lot slower, CAS'd mean a bit slower and more complex code. I will look around if there's anything concrete we could improve.

While this is useful, I think this would best be made into a third party library

I agree on one hand, on the other I opened this proposal because we already use and8, or8 internally and it's such a critical thing that, as a dev, I would rather have it come from core than 3rd party libs.

[bartoszmodelski2]

I did some quick searches with grep and didn't find any good new candidates, hence closing. I'm keen to contribute in this area if there were any opportunities in the future.

[aktau]

I've filed proposal #61395 with a more limited scope (just AND/OR operations).