I am grateful for your apply. The code came from an article introducing go
memory model and we tested it and tried to understand the cause just
because of curiosity.
Thanks the buggy code since now we totally understand when and how to deal
with concurrency in Go more.
在2021年3月12日星期五 UTC+8 下午3:10:23<axel.wa...@googlemail.com> 写道：
> Hi,
>
> I'm sorry. I don't know why the compiler decides to delete the assignment
> in one case but not the other. I doubt there is a better answer than "it
> decides to drop it, because it's faster that way" and "it doesn't drop it,
> because it doesn't realize that it can, for some reason".
>
> However, I also don't understand why it's relevant. Both versions of the
> code are wrong and buggy. And it turns out that this version of this
> compiler surfaces the bug in one case, but not the other. A different
> compiler, or a different version of the same compiler, might surface the
> bug in neither or both cases instead. So if you are asking because you want
> to rely on one behavior or the other, you are (IMO) making a mistake - you
> are introducing compiler-version specific, mysterious bugs. If you are
> asking because you observe similar effects in a non-buggy program which you
> are trying to optimize, we should be talking about that non-buggy program
> instead.
>
> On Fri, Mar 12, 2021 at 7:43 AM WX Lai <0xbi...@gmail.com> wrote:
>
>> Thank you. Yes, the article introducing the go memory model gave precise
>> conditions.
>> However, if fg1 comes like:
>> func fg1() {
>> for x := uint64(0); x < math.MaxUint64; x++ {
>> isRunning--
>> }
>> }
>> or
>> func fg1() {
>> if isRunning > 0 {
>> isRunning = 0
>> }
>> }
>> Then the fg2() will return very quickly.
>> 在2021年3月12日星期五 UTC+8 上午1:19:30<Jan Mercl> 写道：
>>
>>> On Thu, Mar 11, 2021 at 6:12 PM WX Lai <0xbi...@gmail.com> wrote:
>>>
>>> > The code: https://repl.it/talk/share/The-assignment-disappeared/127774
>>> >
>>> > The assignment of the global variable `isRunning` in function `fg1`
>>> does not work at all.
>>> > In fact, the assignment is deleted in the assembly (see the comment of
>>> the link above).
>>> >
>>> > Why the compiler works like this? It disappeared after the process
>>> `short circuit`, after all `isRunning` is used in `main` and `fg2`, making
>>> `fg2` never return.
>>>
>>> The compiler is correct. The change to isRunning is not observable in
>>> the goroutine that executes fg1() so there's no need to actually
>>> update the variable.
>>>
>> --
>>
> 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...@googlegroups.com.
>>
> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/golang-nuts/55a01c10-f593-42a1-82dd-40c2e1523d29n%40googlegroups.com
>>
>> <https://groups.google.com/d/msgid/golang-nuts/55a01c10-f593-42a1-82dd-40c2e1523d29n%40googlegroups.com?utm_medium=email&utm_source=footer>
>> .
>>
>
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/golang-nuts/4a1d68c7-edaa-4084-9bf0-8ea159f893dcn%40googlegroups.com.
