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

Search Discussions

  • Titarooss at Jul 29, 2015 at 3:12 pm
    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:
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Roberto Zanotto at Jul 29, 2015 at 3:50 pm
    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:
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Justin Israel at Jul 29, 2015 at 7:35 pm
    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.


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

    --
    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.
  • Roberto Zanotto at Jul 29, 2015 at 8:16 pm
    ... 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)

    On Wednesday, July 29, 2015 at 9:35:07 PM UTC+2, Justin Israel wrote:

    But what if a zero value is a valid channel value to process? A done
    channel would mean 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.
  • Roberto Zanotto at Jul 29, 2015 at 3:55 pm
    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:
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Bakul Shah at Jul 29, 2015 at 9:12 pm

    On Wed, 29 Jul 2015 01:39:50 PDT Yesudeep Mangalapilly 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.

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

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedJul 29, '15 at 2:14p
activeJul 29, '15 at 9:12p
posts7
users5
websitegolang.org

People

Translate

site design / logo © 2021 Grokbase