-------- 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:
"afterwards".
Why is it important not to break this litmus test?
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:
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 belowOn Wed, May 7, 2014 at 1:15 PM, Nico wrote:
Dmitry,
in the second of the litmus tests you mentioned above:
2.
// 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 {
panic("broken")
}
does the code below "afterwards" belong to a third goroutine or to
goroutine
2?
On 07/05/14 07:17, 'Dmitry Vyukov' via golang-nuts wrote:
no
there is an issue for sync/atomic:
https://code.google.com/p/go/issues/detail?id=5045
no
there is an issue for sync/atomic:
https://code.google.com/p/go/issues/detail?id=5045
Dmitry,
in the second of the litmus tests you mentioned above:
2.
// 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 {
panic("broken")
}
does the code below "afterwards" belong to a third goroutine or to
goroutine
2?
It runs when both goroutines have stored results to r1/r2 in any
goroutine (it's not important).
"afterwards".
Why is it important not to break this litmus test?
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.
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.