add sync.Barrier?

[rsc]

something like this?
seems to come up a lot

// A Barrier waits for a collection of goroutines to finish.
// The main goroutine calls Add to set the number of
// goroutines to wait for.  Then each of the goroutines
// runs and calls Done when finished.  At the same time,
// the main goroutine can call Wait to block until the
// given number of goroutines have finished.

[gopherbot]

Comment 1 by leimy2k:

Naive library based API implementation?
Seems to work with a very basic test.
package barrier
import (
    "sync"
)
type Group struct {
    count int // number of checkins
    total int
    signalin chan bool
    waiter * sync.RWMutex
}
func controller (g * Group) {
    for g.count != g.total {
        <- g.signalin
        g.count++
    }
    g.waiter.Unlock()
}
func NewGroup (size int) (* Group) {
    g := &Group{0,size, make(chan bool, size), &sync.RWMutex{}}
    g.waiter.Lock()
    go controller(g)
    return g
}
func (g * Group) Wait () {
    g.signalin <- true;
    g.waiter.RLock()
}

[gopherbot]

Comment 2 by leimy2k:

Here's the test
package barrier
import (
    "testing"
)
func worker (g * Group, t *testing.T) {
    t.Log("<---")
    g.Wait()
    t.Log("--->")
}
func Test1(t *testing.T) {
    g := NewGroup(10)
    for i := 0; i < 9; i++ {  // we are the last worker
        go worker(g,t)
    }
    
    worker(g,t)
}

[gopherbot]

Comment 3 by leimy2k:

Perhaps a better test:
package barrier
import (
    "testing"
)
func worker (g * Group, t *testing.T, bc chan <- bool) {
    t.Log("<---\n")
    g.Wait()
    t.Log("--->\n")
    bc <- true
}
func Test1(t *testing.T) {
    bc := make(chan bool)
    g := NewGroup(10)
    for i := 0; i < 10; i++ {  // we are the last worker
        go worker(g,t, bc)
    }
    
    for i := 0; i < 10; i++ {
        <- bc
    }
}

[gopherbot]

Comment 4 by leimy2k:

And no I didn't follow the original directions to make an API of Add, Done and Wait,
because I don't think it makes a lot of sense :-).
Then again, I'm coming from an MPI programming background where you have
MPI_Barrier over a communicator, which is really a group of ranks (processes), that all
must call MPI_Barrier for any of them to escape the barrier.

[gopherbot]

Comment 5 by leimy2k:

I implemented a Barrier with the following API for Go.
NewGroup(size)
AddN
Wait.
https://github.com/Leimy/Go-Barrier
There's gotest based unit tests that show how this works.  It's not precisely what's
stated above, but I'm not sure if what's stated above matches what I've read people have
asked for on the golang-nuts group posts which is "the last guy turns off the light".
I implemented that.

[gopherbot]

Comment 6 by leimy2k:

https://github.com/Leimy/Go-Barrier implements 
NewGroup(Size)
AddN(Size)
Wait()
And some examples of how Wait is barrier synchronization are in the barrier_test.go
source file.
Sorry for so many edits.  I've been jumping around tasks and doing a bad job of keeping
this stuff clean :-(

[gopherbot]

Comment 7 by leimy2k:

Not sure I did the codereview correctly but here we go:
http://golang.org/cl/3769044/

[rogpeppe]

Comment 8:

AFAICS there are two quite different APIs here:
- A way for one goroutine to wait for others to complete.
- A way for several goroutines to wait for each other to change computation "phase".
The former is what's being asked for in the initial post in this thread
http://groups.google.com/group/golang-nuts/browse_thread/thread/b26b7e519ef9308
and what Russ proposes above.
The latter is what's being provided by leimy2k above, and is a more convention
semantic for something called a "Barrier".
Both are useful, but for quite different things. I'd suggest that the
former is a more common requirement. The semantics for the latter
need some thinking about (perhaps taking some notice of X10's Clocks?
 - see http://dist.codehaus.org/x10/documentation/languagespec/x10-latest.pdf).
I've attached an implementation, based on some code I wrote some time ago,
that implements the former, with slightly more relaxed semantics than Russ suggests
(neither Add nor Wait need be called in the main goroutine; it allows several goroutines
to wait for the same collection to complete).

Attachments:

1. waiter.go (1260 bytes)

[niemeyer]

Comment 9:

Submitted a proposal closer to the original idea to:
http://golang.org/cl/3770045

[niemeyer]

Comment 10:

By the way, I believe this proposal enables both use cases described with the same
simple API suggested by Russ.

[gopherbot]

Comment 11 by leimy2k:

Might want to put defers around the unlocks but the gist looks pretty good.  
I still think of what I implemented when I hear or read "barrier" but I understand I may
have a different programming background than others, and it may not be what's intended.  
I will still use mine in my own namespaces if my patch is not accepted so just get the
right one for the community.

[niemeyer]

Comment 12:

I'll be happy to, but I can't see a reason to do so given these operations.  Will be
happy to be convinced otherwise, though.
Regarding the distinction of what you implemented, is there any use case you were
looking for which isn't handled by this interface?

[rogpeppe]

Comment 13:

> By the way, I believe this proposal enables both use cases described with the same
simple API suggested by Russ.
i don't think it does.
here's an example that i came across a while ago: implementing
a cellular automaton with concurrent calculation of cells,
a classic barrier algorithm.
the central goroutine looks like this:
func worker(c0, c1 *cells, x0, x1 int, b *Barrier) {
    for {
        calc(c0, c1, x0, x1)
        b.Wait()
        calc(c1, c0, x0, x1)
        b.Wait()
    }
}
it calculates a single stripe of cells within the rectangular cell
array. there's one goroutine for each stripe, and source and
destination cell arrays alternate with each step.
it's crucial that all stripes have finished processing before
the source and destination are swapped.
i'm not sure you could easily use something like russ's proposed
API to do this. e.g. this is wrong:
func worker(c0, c1 *cells, x0, x1 int, b *Barrier) {
    for {
        b.Add(1)
        calc(c0, c1, x0, x1)
        b.Done()
        b.Wait()
        b.Add(1)
        calc(c1, c0, x0, x1)
        b.Done()
        b.Wait()
    }
}

[rogpeppe]

Comment 14:

> Might want to put defers around the unlocks
no. defers are only necessary when you're running arbitrary code that
may panic, and in this case there's no such code (if the code
does panic, then it's a bug and needs fixing a.s.a.p.).
a defer does at least one allocation (currently) so it's worth
avoiding.

[niemeyer]

Comment 15:

It's trivial to enable it to support this case comfortably.  I've added a preset value
which enables you to do this now:
func worker(c0, c1 *cells, x0, x1 int, b *Barrier) {
    for {
        calc(c0, c1, x0, x1)
        b.DoneWait()
        calc(c1, c0, x0, x1)
        b.DoneWait()
    }
}