If we assume no other synchronization here, you have concurrent
modification of variables, which is undefined behavior.
But to answer your original questions: Yes, the behavior of `defer` is
included in the clause "the order expressed by the program" - "the order
specified by the program" doesn't mean "lexical order". `defer` is no
different in that regard than assigning a function literal to a variable
and calling it at a later point - the execution still happens at a later
point, even if the statements in the function literal appear lexically
before the call.
So, yes `defer` implies happens-before relationships: Every return
statement in the function happens-before the deferred execution, which
happens-before the function call returns.
On Wed, May 12, 2021 at 7:56 PM Ge <evergon...@gmail.com> wrote:
> Thank you Jan, sorry for my bad english.
> Do you mean in following case if anthoer goroutine is observing A and B,
> there is no possbility that A is 0 and B is 5? (assuming no other
> synchronization here)
>
> ```
> var A, B int
> func try() {
> defer func() { B = 5 }
> A = 3
> }
>
> Ge
>
> 在2021年5月12日星期三 UTC+8 下午10:48:43<Jan Mercl> 写道：
>
>> On Wed, May 12, 2021 at 4:38 PM Ge <everg...@gmail.com> wrote:
>> >
>> > According to https://golang.org/ref/spec#Defer_statements there is
>> such an expression:
>> > `A "defer" statement invokes a function whose execution is deferred to
>> the moment the surrounding function returns`
>> >
>> > Does `defer` ensure happens-before behaviour with non-defer code?
>>
>> Happens before talks/defines properties/behavior of concurrently
>> executing goroutines. The deferred function is executed in the same
>> goroutine as its surrounding function. Any HB relations wrt other
>> goroutines are the same as if the deferred function was not deferred
>> but explicitly called before just returning from the surrounding
>> function.
>>
>> > However x86 allows out-of-order execution happening across function
>> calls,
>>
>> OOE and other peculiar CPU tricks should not be observable by the Go
>> program, modulo some side channel attacks.
>>
> --
> 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/2bf8beb9-1927-4311-9c7c-32f880bded79n%40googlegroups.com
> <https://groups.google.com/d/msgid/golang-nuts/2bf8beb9-1927-4311-9c7c-32f880bded79n%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/CAEkBMfHJXtPtMcS8NHVpGqs3q210fJfii55XkknqWfWiowKQpw%40mail.gmail.com.
