On Monday, August 17, 2020 at 11:19:16 AM UTC-4 b.ca...@pobox.com wrote:
> On Monday, 17 August 2020 11:54:55 UTC+1, leo.b...@npo-data.nl wrote:
>>
>> E.g. A co-worker pointed out that you can avoid sync.Mutex by using this
>> construct:
>>
>> if !atomic.CompareAndSwapInt32(&s.myLock, 0, 1) {
>> fmt.Println("locked")
>> return
>> }
>> defer atomic.StoreInt32(&s.myLock, 0)
>> processData()
>>
>> Would this synchronise memory?
>>
>
> sync.atomic does synchronise memory, yes.
>
My understanding is that atomic does not 'synchronize memory' in general.
If you use a Mutex, then *everything *that happened before is
'synchronized'. If you use atomic then *only *the atomic variable is
'synchronized'. That is kind of the point of using atomic.
If I am wrong, please point me at the part of the Go Memory Model
<https://golang.org/ref/mem> that says otherwise. Personally, I have always
felt that the go memory model, and specifically the guarantees of the
atomic package are not as rigorously defined as I would like. But in this
case, I'm pretty sure I am correct.
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/0c51e772-cd1e-46ac-a34a-be84aa653cc9n%40googlegroups.com.
