Thanks Robert,
Daves article is mind opening. I created 4 variants of my program to
compare the effects and to give others the chance to study it:
1. https://play.golang.org/p/WE_CbRlfTFf
2. https://play.golang.org/p/FnuzyEVHS-I
3. https://play.golang.org/p/S9ssTxlZK6X
4.
Now I got it - thanks for the explanation.
Am Mi., 19. Dez. 2018 um 02:25 Uhr schrieb :
> > feel unbuffered channels are safer to use especially in an acyclic
> directed graph of flowing values. Buffered channels seem to reduce blocking
> but I feel they come with the cost of such side effects
Unbuffered channels are not dangerous. They just mean that “done sending”
is not the same as “done receiving.” I have done many variations of these
approaches and all work...but I’ve never used select.
On Tue, Dec 18, 2018 at 5:25 PM wrote:
> > feel unbuffered channels are safer to use
> feel unbuffered channels are safer to use especially in an acyclic
directed graph of flowing values. Buffered channels seem to reduce blocking
but I feel they come with the cost of such side effects like my initial
problem of forgotten results in their channels.
that happens with
This may be a helpful read:
https://dave.cheney.net/2013/04/30/curious-channels
> On Dec 18, 2018, at 2:02 PM, robert engels wrote:
>
> To clarify the semantics aspects:
>
> If A cannot proceed until B performs it’s work, because there is a
> dependency, then using a unbuffered channel
To clarify the semantics aspects:
If A cannot proceed until B performs it’s work, because there is a dependency,
then using a unbuffered channel simplifies a lot - you will always be at most
“one event ahead” without any extra synchronization (wait groups, etc.)
> On Dec 18, 2018, at 2:01 PM,
Whether to use buffered or unbuffered comes down to two things:
1) the semantics of the communication. because using unbuffered channels
simplifies a lot - knowing the send will not complete until the read completes
- it provides a synchronization mechanism between events/messages and routines.
What he is saying is that a closed channel is always ready to be received, so
in your code, you could achieve closed++ twice on the same channel...
> On Dec 18, 2018, at 1:38 PM, Chris Burkert wrote:
>
> Justin,
> I don‘t understand that. Maybe I am wrong but I think this is not an issue
>
Robert,
it seems to me that you have a clear understanding about unbuffered vs.
buffered channels. I feel unbuffered channels are safer to use especially
in an acyclic directed graph of flowing values. Buffered channels seem to
reduce blocking but I feel they come with the cost of such side
Justin,
I don‘t understand that. Maybe I am wrong but I think this is not an issue
anymore with the wait group as Ian proposed. It fully replaces the done
channel by closing all result channels while the select keeps on reading
from the result channels until they are all closed and empty. Please
Just realized what you meant about buffered channels. I'm wrong, and sorry
for the confusion.
+1 to your original solution (combined with setting channels to nil).
Diane Looney
On Tue, Dec 18, 2018 at 11:31 AM Chris Burkert
wrote:
> Hello Ian, all,
> yes, the workers generate multiple
I'm not sure this code behaves as you expect it to. I don't think there's
any magic in place to prevent select from picking the same closed channel
more than once. For example:
https://play.golang.org/p/nVvsBxww_Rb
package main
import (
"fmt"
"sync"
)
func test() {
c1 := make(chan bool, 1000)
On Wed, Dec 19, 2018, 5:31 AM Chris Burkert wrote:
> Hello Ian, all,
> yes, the workers generate multiple results. I was able to use your
> proposal with the waiting goroutine which closes the channel. Unfortunately
> my initial minimal example was not so minimal. It is a little more
>
Hello Ian, all,
yes, the workers generate multiple results. I was able to use your proposal
with the waiting goroutine which closes the channel. Unfortunately my
initial minimal example was not so minimal. It is a little more
complicated, as I have multiple "result" channels with different types
On Tue, Dec 18, 2018 at 9:01 AM Skip Tavakkolian
wrote:
>
> why not just drop the select? i think the following is guaranteed because
> putting things on rc has to succeed before putting true into dc:
That will serialize all goroutines. They'll run one after the other.
>
> package main
>
>
Since there are multiple results needed to be processed ...
> On Dec 18, 2018, at 10:02 AM, Robert Engels wrote:
>
> That code is incorrect as well when using buffered channels.
>
>> On Dec 18, 2018, at 10:00 AM, Skip Tavakkolian
>> wrote:
>>
>> why not just drop the select? i think the
That code is incorrect as well when using buffered channels.
> On Dec 18, 2018, at 10:00 AM, Skip Tavakkolian
> wrote:
>
> why not just drop the select? i think the following is guaranteed because
> putting things on rc has to succeed before putting true into dc:
>
> package main
>
>
why not just drop the select? i think the following is guaranteed because
putting things on rc has to succeed before putting true into dc:
package main
import (
"fmt"
)
func do(i int, rc chan<- int, dc chan<- bool) {
rc <- i
dc <- true
}
func main() {
worker := 10
rc := make(chan int, worker)
On Tue, Dec 18, 2018 at 5:35 AM Chris Burkert wrote:
>
> I have a couple of goroutines sending multiple results over a channel - a
> simple fan-in. They signal the completion on a done channel. Main selects on
> the results and done channel in parallel. As the select is random main
> sometimes
On Tue, Dec 18, 2018 at 6:35 AM Chris Burkert wrote:
>
> Dear all,
>
> I have a couple of goroutines sending multiple results over a channel - a
> simple fan-in. They signal the completion on a done channel. Main selects on
> the results and done channel in parallel. As the select is random
Thinking about it, use the expected count, in the done process decrement the
count and only print when 0. Thus works if the channels are unbuffered.
> On Dec 18, 2018, at 7:49 AM, Robert Engels wrote:
>
> This is not trivial, as you are imposing an order on unrelated async events.
>
>
This is not trivial, as you are imposing an order on unrelated async events.
Would you phrase the condition as, do not process a done until I’ve processed
requests for N routines - then you are back to using an expected count.
With an expected count, the problem is trivial.
I think you need
22 matches
Mail list logo
