[go-nuts] Does the Wait function of sync.WaitGroup behave as a memory barrier?

On Tue, May 6, 2014 at 6:55 AM, <kai...@gmail.com <javascript:>> wrote:
Here is some example code that demonstrates my question:

var condition bool
var wg sync.WaitGroup
for _, item := range items {
wg.Add(1)
go func(item) {
if meetsCondition(item) {
condition = true
}
wg.Done()
}(item)
}
wg.Wait()
// is it safe to check condition here?

Does wg.Wait() act as a memory barrier so that it's safe to check
condition?
If not, what's the best way to represent this idiom?

On Tuesday, May 6, 2014 9:12:28 PM UTC-4, Ian Lance Taylor wrote:
(atomic.Load/Store?)

It is safe to check condition after wg.Wait returns.

On the other hand you have several goroutines racing to set condition,
so you should be using atomic.Store anyhow.

Or just send a value on a channel, that always works and doesn't lead
to any of these issues. Untested:

var wg sync.WaitGroup
c := make(chan bool, 1)
for _, item := range items {
wg.Add(1)
go func(item) {
if meetsCondition(item) {
select {
case c <- true:
default:
}
}
wg.Done()
}(item)
}
wg.Wait()
close(c)
condition, _ := <-c

Ian

Well, I figure that the race condition is benign here, since even if a
goroutine sees an old value, all I care about is that by the time wg.Wait()
is finished, condition is either set or unset. But please correct me if I'm
wrong about that.

I like the idea of using channels but I couldn't figure out how to get it
playing nicely with WaitGroup. In your example, you do:

wg.Wait()
close(c)
condition, _ := <-c

But I am under the impression that reading from a closed channel always
returns a zero value, so condition would always be false in this case. Is
that not true here? Otherwise, if we don't close the channel and just try
to do "condition := <-c", then it would hang if "c <- true" is never called
by any goroutine. Although, perhaps I could use a select statement after
wg,Wait(), as in:

wg.Wait()
select {
case <-c:
// do stuff with condition == true
default:
// do other stuff
}

Does that seem reasonable?
--
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 <javascript:>.
For more options, visit https://groups.google.com/d/optout.

On Tuesday, May 6, 2014 9:12:28 PM UTC-4, Ian Lance Taylor wrote:
It is safe to check condition after wg.Wait returns.

On the other hand you have several goroutines racing to set condition,
so you should be using atomic.Store anyhow.

Or just send a value on a channel, that always works and doesn't lead
to any of these issues. Untested:

var wg sync.WaitGroup
c := make(chan bool, 1)
for _, item := range items {
wg.Add(1)
go func(item) {
if meetsCondition(item) {
select {
case c <- true:
default:
}
}
wg.Done()
}(item)
}
wg.Wait()
close(c)
condition, _ := <-c

On Tuesday, May 6, 2014 9:12:28 PM UTC-4, Ian Lance Taylor wrote:
It is safe to check condition after wg.Wait returns.

On the other hand you have several goroutines racing to set condition,
so you should be using atomic.Store anyhow.

Or just send a value on a channel, that always works and doesn't lead
to any of these issues. Untested:

var wg sync.WaitGroup
c := make(chan bool, 1)
for _, item := range items {
wg.Add(1)
go func(item) {
if meetsCondition(item) {
select {
case c <- true:
default:
}
}
wg.Done()
}(item)
}
wg.Wait()
close(c)
condition, _ := <-c

Ian

On Tue, May 6, 2014 at 6:34 PM, Kai Skye wrote:

Well, I figure that the race condition is benign here, since even if a
goroutine sees an old value, all I care about is that by the time wg.Wait()
is finished, condition is either set or unset. But please correct me if I'm
wrong about that.

I like the idea of using channels but I couldn't figure out how to get it
playing nicely with WaitGroup. In your example, you do:

wg.Wait()
close(c)
condition, _ := <-c

But I am under the impression that reading from a closed channel always
returns a zero value, so condition would always be false in this case. Is
that not true here?

Otherwise, if we don't close the channel and just try to
do "condition := <-c", then it would hang if "c <- true" is never called by
any goroutine. Although, perhaps I could use a select statement after
wg,Wait(), as in:

wg.Wait()
select {
case <-c:
// do stuff with condition == true
default:
// do other stuff
}

Does that seem reasonable?

On Tue, May 6, 2014 at 6:34 PM, Kai Skye wrote:
Well, I figure that the race condition is benign here, since even if a
goroutine sees an old value, all I care about is that by the time wg.Wait()
is finished, condition is either set or unset. But please correct me if I'm
wrong about that.

I like the idea of using channels but I couldn't figure out how to get it
playing nicely with WaitGroup. In your example, you do:

wg.Wait()
close(c)
condition, _ := <-c

But I am under the impression that reading from a closed channel always
returns a zero value, so condition would always be false in this case. Is
that not true here? Otherwise, if we don't close the channel and just try to
do "condition := <-c", then it would hang if "c <- true" is never called by
any goroutine. Although, perhaps I could use a select statement after
wg,Wait(), as in:

wg.Wait()
select {
case <-c:
// do stuff with condition == true
default:
// do other stuff
}

Does that seem reasonable?
--
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.

On Tue, May 6, 2014 at 5:55 PM, wrote:
Here is some example code that demonstrates my question:

var condition bool
var wg sync.WaitGroup
for _, item := range items {
wg.Add(1)
go func(item) {
if meetsCondition(item) {
condition = true
}
wg.Done()
}(item)
}
wg.Wait()
// is it safe to check condition here?

Does wg.Wait() act as a memory barrier so that it's safe to check
condition?
If not, what's the best way to represent this idiom? (atomic.Load/Store?)
Thanks!

--
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.

wg.Add happens-before wg.Wait

You need to protect accesses to condition.
Either change it to uint32 and use atomic.StoreUint32 or aggregate
results with a channel:

done := make(chan bool)
for _, item := range items {
go func(item) {
done <- meetsCondition(item)
}(item)
}
cond := false
for _ := range items {
cond = cond | <-done
}


--
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.

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

On 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 10:59, Dmitry Vyukov wrote:
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.

On 07/05/14 11:44, Dmitry Vyukov wrote:
What exactly deviations from sequential consistency do you mean?

On 08/05/14 07:22, Dmitry Vyukov wrote:

There are control dependencies involved.

On 09/05/14 12:12, Dmitry Vyukov wrote:
What control dependencies would apply to buffered channels?

For example, if a chan operation blocks forever, then nothing below it
can hoist above it. Otherwise the program will execute something that
it must not execute.