Significance of using a buffered channel of capacity 1.

[Yesudeep Mangalapilly]

Namaste,

I'm new to concurrency and Go, so my question may be a bit naive. 

While reading through this example here:

http://play.golang.org/p/0DfW-1RMqi

--- code ---

package main

import "fmt"

import "time"

func worker(done chan bool) {

    time.Sleep(time.Second)

    done <- true

}

func main() {

    done := make(chan bool, 1)    // What is the significance of using 1 as capacity here?

    go worker(done)

    <-done

}

--- end code ---

Why use 1 to create a buffered channel? Can we not signal "done" using a regular non-buffered

channel?

Cheers,

Yesudeep.

[tita...@gmail.com]

Yes, you could. I'm guessing this example is building upon a previous example, or may be used in a subsequent example, building up to a larger more complex example of channels through a series of tutorials. It is also possible that it is just an oversight. where is this example from ?

[Roberto Zanotto]

I guess the buffer is to make communication asynchronous. With unbuffered channels, when a goroutine sends a message to the channel, it blocks until there's another goroutine that is ready to receive the message (the channel does both communication _and_ synchronization between goroutines). If you use a buffer instead, the message is dropped in the buffer and the send operation is not blocking (if there's room in the buffer, of course).

That said, writing to a buffered channel is probably not the best way of signaling completion. It's best to close the channel instead of writing to it (and possibly using a chan of struct{}). Closing operation is always non blocking and if other goroutines (also more than one) are waiting to read a message they will get the zero value of the message when the channel gets closed.

Hope I was able to explain it clearly :) maybe you should watch a video about concurrency patterns in Go.

Cheers.

[Roberto Zanotto]

Also, in this particular example, sending a message to an unbuffered channel would have been just fine. But in some cases, using a buffer (or closing the channel instead of sending) to make communication asynchronous can avoid deadlocks.

On Wednesday, July 29, 2015 at 4:14:21 PM UTC+2, Yesudeep Mangalapilly wrote:

[Justin Israel]

On Thu, 30 Jul 2015 3:50 AM Roberto Zanotto <roby...@gmail.com> wrote:

I guess the buffer is to make communication asynchronous. With unbuffered channels, when a goroutine sends a message to the channel, it blocks until there's another goroutine that is ready to receive the message (the channel does both communication _and_ synchronization between goroutines). If you use a buffer instead, the message is dropped in the buffer and the send operation is not blocking (if there's room in the buffer, of course).

That said, writing to a buffered channel is probably not the best way of signaling completion. It's best to close the channel instead of writing to it (and possibly using a chan of struct{}). Closing operation is always non blocking and if other goroutines (also more than one) are waiting to read a message they will get the zero value of the message when the channel gets closed.

But what if a zero value is a valid channel value to process? A done channel would mean done.

Hope I was able to explain it clearly :) maybe you should watch a video about concurrency patterns in Go.

Cheers.

On Wednesday, July 29, 2015 at 4:14:21 PM UTC+2, Yesudeep Mangalapilly wrote:

Namaste,

I'm new to concurrency and Go, so my question may be a bit naive. 

While reading through this example here:

http://play.golang.org/p/0DfW-1RMqi

--- code ---

package main

import "fmt"

import "time"

func worker(done chan bool) {

    time.Sleep(time.Second)

    done <- true

}

func main() {

    done := make(chan bool, 1)    // What is the significance of using 1 as capacity here?

    go worker(done)

    <-done

}

--- end code ---

Why use 1 to create a buffered channel? Can we not signal "done" using a regular non-buffered

channel?

Cheers,

Yesudeep.

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

[Roberto Zanotto]

... that's the point. If the channel is a "done" channel, it's there only to signal when the taks it's done, there's no value to process (that's why I would use a chan of struct{}).

So when you want to wait for the task to be completed, you do:

<-done

And that blocks until the channel gets closed (when the job is done). And you get nothing (an empty struct) out of the channel, because there's no data to process.

(hope I didn't misunderstand your question)

[Bakul Shah]

On Wed, 29 Jul 2015 01:39:50 PDT Yesudeep Mangalapilly <yesu...@gmail.com> wrote:
> --- code ---
> package main
>
> import "fmt"
> import "time"
>
> func worker(done chan bool) {
> time.Sleep(time.Second)
> done <- true
> }
>
> func main() {
> done := make(chan bool, 1) // What is the significance of using 1 as
> capacity here?
> go worker(done)
> <-done
> }
> --- end code ---
>
> Why use 1 to create a buffered channel? Can we not signal "done" using a
> regular non-buffered channel?

In general, synchronize only when you have to. Here the main
thread wants to know when the worker thread terminates but the
worker thread doesn't care when the main thread gets around to
reading from "done". Using a 1 deep buffer channel exactly
captures this usage pattern. An unbuffered channel would make
the worker thread "rendezvous" with the main thread, which is
unnecessary.

[Deepak Pathak]

IMHO, this is so that the sender of ths signal to your channel doesn't gets blocked. 

A helpful blog to understand it: https://www.rudderstack.com/blog/implementing-graceful-shutdown-in-go/

Hope it helps!