4 ms·

What are the concurrency guarantees of goroutines? ;)

DuskStar 7y ago
I'm confused here too - is there some other desired behavior? I thought the goal here was to avoid race conditions and just reproduce that order, since that's what's in the source code... > var buttons = []string{"red", "blue", "green", "yellow", "purple"}
Thorrez 7y ago
There are none, right? So even if you add mutexes to the existing code in an attempt to remove race conditions, it will still have race conditions, and have no guaranteed output order, because you have no guarantee which order the goroutines will start in. The obvious way to solve it in order to get the answer shown in the source code is if x == 0 { *sequence = []Button{{"red"}, {"blue"}, {"green"}, {"yellow"}, {"purple"}} } return This way there is nothing concurrently touching sequence, nor is there anything concurrent touching rand, nor is anything relying on goroutine starting order, nor are there other race conditions. But yet the site says this is wrong.
- everdev 7y ago
  You can click the lightbulb to get a hint. The way I solved it was with a Mutex.
  - Thorrez 7y ago
    Yeah I know about the hint. But the result the hint leads you to doesn't make sense. Using a Mutex removes data races, but it does not remove race conditions. By leaving the race condition in, the code is has output that cannot be relied on. But yet the challenge wants us to think that somehow the output has a specific value that can be relied on.
- AlexCoventry 7y ago
  It turns out there is a guaranteed order, because of the way this puzzle is executed. https://bit.ly/2rqqWkh https://bit.ly/2rqqWkh
  - Thorrez 7y ago
    Where is this guarantee stated? I don't see anything on that page about a guarantee. Does the go spec make this guarantee? How do we know how the puzzle is executed? And if you're saying some guarantee exists that the last executes first, then the rest execute in order, that's empirically false: https://play.golang.org/p/3gV0TYG4GQW https://play.golang.org/p/3gV0TYG4GQW 1000 773 774 775 776 ...
    - AlexCoventry 7y ago
      I'm not saying it's a good guarantee.

I'm confused here too - is there some other desired behavior? I thought the goal here was to avoid race conditions and just reproduce that order, since that's what's in the source code... > var buttons = []string{"red", "blue", "green", "yellow", "purple"}

Thorrez 7y ago

There are none, right? So even if you add mutexes to the existing code in an attempt to remove race conditions, it will still have race conditions, and have no guaranteed output order, because you have no guarantee which order the goroutines will start in. The obvious way to solve it in order to get the answer shown in the source code is if x == 0 { *sequence = []Button{{"red"}, {"blue"}, {"green"}, {"yellow"}, {"purple"}} } return This way there is nothing concurrently touching sequence, nor is there anything concurrent touching rand, nor is anything relying on goroutine starting order, nor are there other race conditions. But yet the site says this is wrong.

everdev 7y ago
You can click the lightbulb to get a hint. The way I solved it was with a Mutex.
- Thorrez 7y ago
  Yeah I know about the hint. But the result the hint leads you to doesn't make sense. Using a Mutex removes data races, but it does not remove race conditions. By leaving the race condition in, the code is has output that cannot be relied on. But yet the challenge wants us to think that somehow the output has a specific value that can be relied on.
AlexCoventry 7y ago
It turns out there is a guaranteed order, because of the way this puzzle is executed. https://bit.ly/2rqqWkh https://bit.ly/2rqqWkh
- Thorrez 7y ago
  Where is this guarantee stated? I don't see anything on that page about a guarantee. Does the go spec make this guarantee? How do we know how the puzzle is executed? And if you're saying some guarantee exists that the last executes first, then the rest execute in order, that's empirically false: https://play.golang.org/p/3gV0TYG4GQW https://play.golang.org/p/3gV0TYG4GQW 1000 773 774 775 776 ...
  - AlexCoventry 7y ago
    I'm not saying it's a good guarantee.