[go-nuts] Significance of using a buffered channel of capacity 1.

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 ?

On Wednesday, July 29, 2015 at 10:14:21 AM UTC-4, Yesudeep Mangalapilly
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.
Hope I was able to explain it clearly :) maybe you should watch a video
about concurrency patterns <https://www.youtube.com/watch?v=f6kdp27TYZs> in
Go.
Cheers.

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

On Thu, 30 Jul 2015 3:50 AM Roberto Zanotto 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 <https://www.youtube.com/watch?v=f6kdp27TYZs> 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.

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

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:

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.