Always a good read on why that is still a problem:
Benign Data Races: What Could Possibly Go Wrong?
<https://software.intel.com/en-us/blogs/2013/01/06/benign-data-races-what-could-possibly-go-wrong>
It is not specific to go, but mostly applies to any language, and is stuff
all developers should know.
On Friday, February 1, 2019 at 4:58:11 PM UTC-5, Michael Ellis wrote:
>
>
>
> On Friday, February 1, 2019 at 11:11:24 AM UTC-5, robert engels wrote:
>>
>>
>> for {
>> if A.a > 100 {
>> break
>> }
>>
>>
>> Go routine #2 may never see the value of A.a change and so never exit the
>> loop.
>>
>
> I'm confused. I can see how that would fail if the test were A.a == 100
> since Go routine #1 might increment past 100 before #2 , but as written it
> seems wrong only if the application logic depends on Go routine #2 exiting
> the loop as soon as A.a reaches 100 (as opposed to any time afterward.)
>
> What am I missing?
>
>
>>
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
