-------- Original Message --------
Subject: Re: [go-nuts] Does the Wait function of sync.WaitGroup behave
as a memory barrier?
Date: Wed, 7 May 2014 13:59:20 +0400
From: Dmitry Vyukov
To: Nico

On Wed, May 7, 2014 at 1:56 PM, Nico wrote:
On 07/05/14 10:38, Dmitry Vyukov wrote:
On Wed, May 7, 2014 at 1:15 PM, Nico wrote:
On 07/05/14 07:17, 'Dmitry Vyukov' via golang-nuts wrote:

there is an issue for sync/atomic:


in the second of the litmus tests you mentioned above:


// goroutine 1
atomic.Store(&X, 1)
r1 = atomic.Load(&Y)

// goroutine 2
atomic.Store(&Y, 1)
r2 = atomic.Load(&X)

// afterwards
if r1 == 0 && r2 == 0 {

does the code below "afterwards" belong to a third goroutine or to

It runs when both goroutines have stored results to r1/r2 in any
goroutine (it's not important).
OK, so both atomic loads happen before the execution of the code below

Why is it important not to break this litmus test?
Because otherwise the model allows not sequentially-consistent
executions. It's extremely difficult to reason about non
sequentially-consistent executions.


My opinion about issue 5045 is that:

- sync/atomic should already guarantee the litmus test 1 (I don't see a
reason not to make the change in the documentation now; I imagine everyone
using sync/atomic expects this guarantee to hold)

- the documentation in sync/atomic can be updated again once a decision has
been made about the litmus test 2.

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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Search Discussions

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
postedMay 7, '14 at 10:32a
activeMay 7, '14 at 10:32a

1 user in discussion

N. Riesco - GMail: 1 post



site design / logo © 2022 Grokbase