FAQ
var c = make(chan int, 10)
var a string

func f() {
a = "hello, world"
c <- 0
}

func main() {
go f()
<-c
print(a)
}

is guaranteed to print "hello, world". The write to a happens before the
send on c, which happens before the corresponding receive on c completes,
which happens before the print.


"The write to a happens before the send on c", why processor is certainly
not reordering it?

--
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+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

  • Jan Mercl at Feb 26, 2013 at 12:51 pm

    On Tue, Feb 26, 2013 at 9:28 AM, WENBO HUANG wrote:
    "The write to a happens before the send on c", why processor is certainly
    not reordering it?
    You're confusing program (sequence of statements) execution and CPU
    (sequence of machine instruction codes w/ the appropriate
    memory/register effects) execution. The docs sentence is about the
    former. The observed changes to a are again from the program point of
    view. Moreover, a channel operation is not equal to a simple memory
    operation, so even the "CPU" (write) reordering is not (generally)
    applicable.

    Roughly: The memory model specs in this case forces the compiler
    writer to flush 'a' to memory if it happens to be in a register only
    before that. That is legal as long as there's no sync by channel
    communication (or atomic or lock operations, IIRC).

    -j

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • WENBO HUANG at Feb 26, 2013 at 1:23 pm
    I think I'm not confusing. And you answered the question:
    "Moreover, a channel operation is not equal to a simple memory
    operation, so even the "CPU" (write) reordering is not (generally)
    applicable. "

    在 2013年2月26日星期二UTC+8下午8时51分16秒,Jan Mercl写道:
    On Tue, Feb 26, 2013 at 9:28 AM, WENBO HUANG wrote:
    "The write to a happens before the send on c", why processor is certainly
    not reordering it?
    You're confusing program (sequence of statements) execution and CPU
    (sequence of machine instruction codes w/ the appropriate
    memory/register effects) execution. The docs sentence is about the
    former. The observed changes to a are again from the program point of
    view. Moreover, a channel operation is not equal to a simple memory
    operation, so even the "CPU" (write) reordering is not (generally)
    applicable.

    Roughly: The memory model specs in this case forces the compiler
    writer to flush 'a' to memory if it happens to be in a register only
    before that. That is legal as long as there's no sync by channel
    communication (or atomic or lock operations, IIRC).

    -j
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Nagle at Feb 26, 2013 at 7:06 pm

    On 2/26/2013 4:51 AM, Jan Mercl wrote:
    Roughly: The memory model specs in this case forces the compiler
    writer to flush 'a' to memory if it happens to be in a register only
    before that. That is legal as long as there's no sync by channel
    communication (or atomic or lock operations, IIRC).
    See "http://golang.org/ref/mem", which describes which operations
    force memory synchronization between goroutines. There are two
    main events that force memory synchronization (a "memory fence"
    operation at the CPU level):

    - Receive on a channel.
    - Unlock on a mutex lock.

    Note that merely sending does not force synchronization;
    someone has to receive.

    Similarly, it's not mutex locking that triggers synchronization;
    it's unlocking. Entering a locked section of code and accessing
    shared data which was modified outside a locked section
    from another goroutine creates a potential race condition.

    This is very real in Go. There are programs which demo
    these race conditions on multiple-CPU machines.

    John Nagle



    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jan Mercl at Feb 26, 2013 at 8:23 pm
    On Tue, Feb 26, 2013 at 8:00 PM, John Nagle wrote:

    I don't agree with your view of that document. You have bashed the
    same/similar thing about Go in dozens of threads and I refuse to go
    into the same details again. Just check the compilers sources for your
    self, its FOSS and it is worth of the study.

    Anyway, Go is broken in your eyes, so let it be. Perhaps there is some
    other language which isn't and you can enlighten its mailing list
    instead.

    -j

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Nagle at Feb 26, 2013 at 8:52 pm

    On 2/26/2013 12:23 PM, Jan Mercl wrote:
    On Tue, Feb 26, 2013 at 8:00 PM, John Nagle wrote:

    I don't agree with your view of that document. You have bashed the
    same/similar thing about Go in dozens of threads and I refuse to go
    into the same details again.
    You are free to cease writing.

    Go users need to know that race conditions are possible and how
    to prevent them. It's not hard. The rather dense Go Memory Model
    paper can be summarized for users as:

    There are only a few events that force memory synchronization:

    - Receive on a channel.
    - Unlock on a mutex lock.

    If a variable has been changed by one goroutine, you must do
    one of those before accessing that variable in another goroutine.

    John Nagle

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jan Mercl at Feb 26, 2013 at 9:19 pm

    On Tue, Feb 26, 2013 at 9:52 PM, John Nagle wrote:
    Go users need to know that race conditions are possible
    Some Go users are aware of that _races in the implementation are
    possible_ years before you discovered the existence of the Go
    programming language (http://research.swtch.com/gorace).

    Though you're consistently "teaching" that it is the problem of the
    language, which is not true.
    and how
    to prevent them. It's not hard. The rather dense Go Memory Model
    paper can be summarized for users as:
    Go users are not dependent on you to teach them. Especially not when
    the teaching is incorrect.
    There are only a few events that force memory synchronization:

    - Receive on a channel.
    - Unlock on a mutex lock.
    It's simply not what is in the talked about document and AFAICS it is
    not true. Please cite the document relevant parts and correctly derive
    your result.
    If a variable has been changed by one goroutine, you must do
    one of those before accessing that variable in another goroutine.
    Not true. Let's return to the OP problem and let's look what the
    document has to say about it:

    [Q]
    "The write to a happens before the send on c, which happens before the
    corresponding receive on c completes, which happens before the print."
    [/Q]

    It not "dense". Before the send on 'c' the write to 'a' has happened.
    I.e. if 'a' was for example held in a register (unsynced), it was
    expelled to memory before the send to c happened.

    I might be wrong, the doc might be wrong, of course. Just point out
    where the mistake is, please.

    TIA

    -j

    PS: The other, receiving side is simple as well, but let's first
    figure out the "The write to a happens before the send on c" thing
    before going any further, ok?

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • John Nagle at Feb 26, 2013 at 10:06 pm

    On 2/26/2013 1:19 PM, Jan Mercl wrote:
    On Tue, Feb 26, 2013 at 9:52 PM, John Nagle
    wrote: Though you're
    consistently "teaching" that it is the problem of the language, which
    is not true.
    If it wasn't a problem, the Go Playground and Google AppEngine
    wouldn't be locked down to single-thread.
    There are only a few events that force memory synchronization:

    - Receive on a channel. - Unlock on a mutex lock.
    It's simply not what is in the talked about document and AFAICS it
    is not true. Please cite the document relevant parts and correctly
    derive your result.
    That comes from the statements in "http://golang.org/ref/mem":

    "Within a single goroutine, the happens-before order is the order
    expressed by the program."

    "A send on a channel happens before the corresponding receive from that
    channel completes."

    "For any sync.Mutex or sync.RWMutex variable l and n < m, call n of
    l.Unlock() happens before call m of l.Lock() returns."

    Therefore, the user is guaranteed sequential operations from one
    goroutine to another if a channel receive intervenes. The receive
    is the synchronizing operation, not the send. Similarly, Unlock
    (or really, return from Lock) is the synchronizing operation,
    not Lock. This is as it should be.

    Mercl is right, though; I'm oversimplifying. If one goroutine
    sends to a channel that has some items queued, and the receiver gets
    an item that was already in the channel, a Go implementation is not
    strictly required to synchronize memory up to the last send to the
    channel, only to the state at the time the item being read
    entered the channel. In practice an implementation probably
    does a global memory fence operation on each channel receive,
    but the spec is a bit looser than that.

    How strict is Go's race detector about this? Does it track
    state through channel queues, or does it just treat some
    events as a commit?

    (I once spent several years fixing a major mainframe operating
    system by reading crash dumps from production machines.
    This makes one very aware of race conditions as defects.
    I never want to do that again.)

    John Nagle

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jan Mercl at Feb 26, 2013 at 10:44 pm

    On Tue, Feb 26, 2013 at 11:06 PM, John Nagle wrote:
    On 2/26/2013 1:19 PM, Jan Mercl wrote:
    On Tue, Feb 26, 2013 at 9:52 PM, John Nagle
    wrote: Though you're
    consistently "teaching" that it is the problem of the language, which
    is not true.
    If it wasn't a problem, the Go Playground and Google AppEngine
    wouldn't be locked down to single-thread.
    Makes me wonder if the difference between a language and its
    implementation is somehow incomprehensible?
    There are only a few events that force memory synchronization:

    - Receive on a channel. - Unlock on a mutex lock.
    It's simply not what is in the talked about document and AFAICS it
    is not true. Please cite the document relevant parts and correctly
    derive your result.
    That comes from the statements in "http://golang.org/ref/mem":

    "Within a single goroutine, the happens-before order is the order
    expressed by the program."

    "A send on a channel happens before the corresponding receive from that
    channel completes."

    "For any sync.Mutex or sync.RWMutex variable l and n < m, call n of
    l.Unlock() happens before call m of l.Lock() returns."

    Therefore, the user is guaranteed sequential operations from one
    goroutine to another if a channel receive intervenes. The receive
    is the synchronizing operation, not the send. Similarly, Unlock
    (or really, return from Lock) is the synchronizing operation,
    not Lock. This is as it should be.
    The guarantees are both stricter and simpler (in the first approximation).

    As we haven't yet gone through this point, it probably has to be repeated:

    [Q]
    "The write to a happens before the send on c, which happens before the
    corresponding receive on c completes, which happens before the print."
    [/Q]

    The write to 'a' happens before send on 'c', so a channel receive has
    nothing (yet) to do with it. That's stricter, b/c it means that after
    a send on 'c', 'a' is already in a correct state. It's simpler, b/c
    the channel read is not required for "write to 'a' _happen before_
    send on 'c'". The send on 'c' means 'a' is now in sync with the code
    (`a = <expression>`).

    Let me postpone discussion of the situation in the receiving goroutine
    to the moment when this is figured out first.

    -j

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Watson Ladd at Feb 27, 2013 at 2:12 am

    On Tuesday, February 26, 2013 4:43:49 PM UTC-6, Jan Mercl wrote:
    On Tue, Feb 26, 2013 at 11:06 PM, John Nagle wrote:
    On 2/26/2013 1:19 PM, Jan Mercl wrote:
    On Tue, Feb 26, 2013 at 9:52 PM, John Nagle
    <na...@animats.com <javascript:>> wrote: Though you're
    consistently "teaching" that it is the problem of the language, which
    is not true.
    If it wasn't a problem, the Go Playground and Google AppEngine
    wouldn't be locked down to single-thread.
    Makes me wonder if the difference between a language and its
    implementation is somehow incomprehensible?
    There are only a few events that force memory synchronization:

    - Receive on a channel. - Unlock on a mutex lock.
    It's simply not what is in the talked about document and AFAICS it
    is not true. Please cite the document relevant parts and correctly
    derive your result.
    That comes from the statements in "http://golang.org/ref/mem":

    "Within a single goroutine, the happens-before order is the order
    expressed by the program."

    "A send on a channel happens before the corresponding receive from that
    channel completes."

    "For any sync.Mutex or sync.RWMutex variable l and n < m, call n of
    l.Unlock() happens before call m of l.Lock() returns."

    Therefore, the user is guaranteed sequential operations from one
    goroutine to another if a channel receive intervenes. The receive
    is the synchronizing operation, not the send. Similarly, Unlock
    (or really, return from Lock) is the synchronizing operation,
    not Lock. This is as it should be.
    The guarantees are both stricter and simpler (in the first approximation).

    As we haven't yet gone through this point, it probably has to be repeated:

    [Q]
    "The write to a happens before the send on c, which happens before the
    corresponding receive on c completes, which happens before the print."
    [/Q]

    The write to 'a' happens before send on 'c', so a channel receive has
    nothing (yet) to do with it. That's stricter, b/c it means that after
    a send on 'c', 'a' is already in a correct state. It's simpler, b/c
    the channel read is not required for "write to 'a' _happen before_
    send on 'c'". The send on 'c' means 'a' is now in sync with the code
    (`a = <expression>`).

    Let me postpone discussion of the situation in the receiving goroutine
    to the moment when this is figured out first.
    John is actually correct. The important part is the first line of the
    model: they are defining a partial ordering on statements called "foo"
    <tabooing mention of time because
    it is misleading.> They then define a relation bar between writes and
    reads. A read is bar with a write if the read is foo with respect to a
    write and there is no other write
    that is foo with the given write to which the read is foo. A read is bax
    with a write if it is bar with a write and all other writes are foo to the
    write or the read is foo to them.

    In a single goroutine the foo relation subsumes textual ordering. However,
    there is no guarantee that foo is a total ordering, and so it is only
    necessary that the result of a write is reflected in reads that are foo to
    it, so it suffices to commit it chronologically before the read that is foo
    to it.

    This is pedantic, but necessary. In particular if we have the following set
    of relations:
    A foo B
    A foo C
    B foo D
    C foo E
    D foo F
    E foo F

    Then it is not the case that either B foo E or E foo B, while in the total
    ordering case this is correct. In particular a single-threaded
    implementation would have this work
    with foo defined as chronology, while a multiply threaded one could do
    anything.

    Sincerely,
    Watson Ladd
    -j
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Lapensee at Feb 26, 2013 at 1:27 pm
    The write to a happens before the send on c
    the write to a happends before the "c <- 0"
    which happens before the corresponding receive on c completes
    no, after "go f()", the program can continue to "<-c", and can continue on
    to "print(a)" before the a = "hello, world"
    because your channel is buffered for 10 entries.

    at the "print(a)", it MAY have assigned a, but it MAY NOT have.

    Regards,

    Rob Lapensee



    On Tuesday, February 26, 2013 3:28:28 AM UTC-5, WENBO HUANG wrote:

    var c = make(chan int, 10)
    var a string

    func f() {
    a = "hello, world"
    c <- 0
    }

    func main() {
    go f()
    <-c
    print(a)
    }

    is guaranteed to print "hello, world". The write to a happens before the
    send on c, which happens before the corresponding receive on c completes,
    which happens before the print.


    "The write to a happens before the send on c", why processor is certainly
    not reordering it?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Minux at Feb 26, 2013 at 1:32 pm

    On Tue, Feb 26, 2013 at 9:26 PM, Rob Lapensee wrote:
    The write to a happens before the send on c
    the write to a happends before the "c <- 0"
    which happens before the corresponding receive on c completes
    no, after "go f()", the program can continue to "<-c", and can continue on
    to "print(a)" before the a = "hello, world"
    because your channel is buffered for 10 entries.
    incorrect. how can it continue past "<-c" if "c <- 0" doesn't happen before
    it?
    at the "print(a)", it MAY have assigned a, but it MAY NOT have.
    are you asserting the example in the official Go memory model is wrong?

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Rob Lapensee at Feb 26, 2013 at 1:34 pm
    sorry, my bad,
    I had "which is send" and "which is receive' backwords.
    On Tuesday, February 26, 2013 8:31:43 AM UTC-5, minux wrote:


    On Tue, Feb 26, 2013 at 9:26 PM, Rob Lapensee <robl....@gmail.com<javascript:>
    wrote:
    The write to a happens before the send on c
    the write to a happends before the "c <- 0"
    which happens before the corresponding receive on c completes
    no, after "go f()", the program can continue to "<-c", and can continue
    on to "print(a)" before the a = "hello, world"
    because your channel is buffered for 10 entries.
    incorrect. how can it continue past "<-c" if "c <- 0" doesn't happen
    before it?
    at the "print(a)", it MAY have assigned a, but it MAY NOT have.
    are you asserting the example in the official Go memory model is wrong?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Jan Mercl at Feb 26, 2013 at 1:36 pm

    On Tue, Feb 26, 2013 at 2:26 PM, Rob Lapensee wrote:
    The write to a happens before the send on c
    the write to a happends before the "c <- 0"

    which happens before the corresponding receive on c completes
    no, after "go f()", the program can continue to "<-c", and can continue on
    to "print(a)" before the a = "hello, world"
    because your channel is buffered for 10 entries.

    at the "print(a)", it MAY have assigned a, but it MAY NOT have.
    No. No receive from a channel before a send to it can even happen.
    Buffered or not.

    -j

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David DENG at Feb 27, 2013 at 3:18 am
    1. the processor (CPU) never reorders code, just pipeline or parallel at
    most
    2. the compiler may reorder (the generated code of) some statements only
    if,
    3. the generated code is logically equivallent to the original one

    Hope this help.

    David
    On Tuesday, February 26, 2013 4:28:28 PM UTC+8, WENBO HUANG wrote:

    var c = make(chan int, 10)
    var a string

    func f() {
    a = "hello, world"
    c <- 0
    }

    func main() {
    go f()
    <-c
    print(a)
    }

    is guaranteed to print "hello, world". The write to a happens before the
    send on c, which happens before the corresponding receive on c completes,
    which happens before the print.


    "The write to a happens before the send on c", why processor is certainly
    not reordering it?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • WENBO HUANG at Feb 27, 2013 at 3:42 am
    "the processor (CPU) never reorders code, just pipeline or parallel at
    most".
    So these two a = "hello, world" and c <- 0 may parallel execute at same
    time if go doesn't guarantee it.
    I want to know if "The write to a happens before the send on c" is go
    memory model spec guarantee.

    在 2013年2月27日星期三UTC+8上午11时18分11秒,David DENG写道:

    1. the processor (CPU) never reorders code, just pipeline or parallel
    at most
    2. the compiler may reorder (the generated code of) some statements
    only if,
    3. the generated code is logically equivallent to the original one

    Hope this help.

    David
    On Tuesday, February 26, 2013 4:28:28 PM UTC+8, WENBO HUANG wrote:

    var c = make(chan int, 10)
    var a string

    func f() {
    a = "hello, world"
    c <- 0
    }

    func main() {
    go f()
    <-c
    print(a)
    }

    is guaranteed to print "hello, world". The write to a happens before the
    send on c, which happens before the corresponding receive on c completes,
    which happens before the print.


    "The write to a happens before the send on c", why processor is
    certainly not reordering it?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David DENG at Feb 27, 2013 at 3:45 am
    Go compiler and the CPU both guarantee no matter what they do(reordering,
    parallel, pipeline), the *results* are just as expected.

    David
    On Wednesday, February 27, 2013 11:42:16 AM UTC+8, WENBO HUANG wrote:

    "the processor (CPU) never reorders code, just pipeline or parallel at
    most".
    So these two a = "hello, world" and c <- 0 may parallel execute at same
    time if go doesn't guarantee it.
    I want to know if "The write to a happens before the send on c" is go
    memory model spec guarantee.

    在 2013年2月27日星期三UTC+8上午11时18分11秒,David DENG写道:

    1. the processor (CPU) never reorders code, just pipeline or parallel
    at most
    2. the compiler may reorder (the generated code of) some statements
    only if,
    3. the generated code is logically equivallent to the original one

    Hope this help.

    David
    On Tuesday, February 26, 2013 4:28:28 PM UTC+8, WENBO HUANG wrote:

    var c = make(chan int, 10)
    var a string

    func f() {
    a = "hello, world"
    c <- 0
    }

    func main() {
    go f()
    <-c
    print(a)
    }

    is guaranteed to print "hello, world". The write to a happens before
    the send on c, which happens before the corresponding receive on c completes,
    which happens before the print.


    "The write to a happens before the send on c", why processor is
    certainly not reordering it?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Watson Ladd at Feb 27, 2013 at 3:46 am
    Yes, see section 2 of the Go Memory Model, in particular
    "Within a single goroutine, the happens-before order is the order expressed
    by the program."
    Since the assignment and the send are in the same goroutine, the assignment
    happens-before the send.
    Sincerely,
    Watson Ladd
    On Tuesday, February 26, 2013 9:42:16 PM UTC-6, WENBO HUANG wrote:

    "the processor (CPU) never reorders code, just pipeline or parallel at
    most".
    So these two a = "hello, world" and c <- 0 may parallel execute at same
    time if go doesn't guarantee it.
    I want to know if "The write to a happens before the send on c" is go
    memory model spec guarantee.

    在 2013年2月27日星期三UTC+8上午11时18分11秒,David DENG写道:

    1. the processor (CPU) never reorders code, just pipeline or parallel
    at most
    2. the compiler may reorder (the generated code of) some statements
    only if,
    3. the generated code is logically equivallent to the original one

    Hope this help.

    David
    On Tuesday, February 26, 2013 4:28:28 PM UTC+8, WENBO HUANG wrote:

    var c = make(chan int, 10)
    var a string

    func f() {
    a = "hello, world"
    c <- 0
    }

    func main() {
    go f()
    <-c
    print(a)
    }

    is guaranteed to print "hello, world". The write to a happens before
    the send on c, which happens before the corresponding receive on c completes,
    which happens before the print.


    "The write to a happens before the send on c", why processor is
    certainly not reordering it?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Watson Ladd at Feb 27, 2013 at 3:44 am

    On Tuesday, February 26, 2013 9:18:11 PM UTC-6, David DENG wrote:

    1. the processor (CPU) never reorders code, just pipeline or parallel
    at most
    2. the compiler may reorder (the generated code of) some statements
    only if,
    3. the generated code is logically equivallent to the original one

    These two statements are all wrong. The Alpha is notorious for reordering
    code, and on most CPUs loads and stores can complete after arithmetic
    operations
    that are dispached later. On some superscalar designs there is no global
    ordering of instructions, because each operational unit has its own queue
    of operations,
    and magic keeps the results consistent. Any CPU that does not have precise
    exceptions at all times does not have a concept of time in which
    instructions are externally
    visible or not depending on whether before or after a point in the
    instruction sequence, and most CPU architectures do not for increased
    performance.

    As for compilers, the real question is what is logically equivalent.
    Peterson's algorithm is not guarantied in Go to work.
    Hope this help.

    David
    On Tuesday, February 26, 2013 4:28:28 PM UTC+8, WENBO HUANG wrote:

    var c = make(chan int, 10)
    var a string

    func f() {
    a = "hello, world"
    c <- 0
    }

    func main() {
    go f()
    <-c
    print(a)
    }

    is guaranteed to print "hello, world". The write to a happens before the
    send on c, which happens before the corresponding receive on c completes,
    which happens before the print.


    "The write to a happens before the send on c", why processor is
    certainly not reordering it?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • David DENG at Feb 27, 2013 at 3:55 am
    1. Ok. Sorry for the first statement, I do not know much about different
    kinda CPUs . :-P. But CPU, in my mind, is always in the way I just
    mentioned. Only the writers of compiler has to make people like me happy
    even the CPU makes them unhappy.

    2. This statement needs to be further clarified: logically equivallent see
    from the same thread or go-routine. From outside of the go-routine, it
    could be different. That's what memory modle is about.

    David
    On Wednesday, February 27, 2013 11:44:28 AM UTC+8, Watson Ladd wrote:

    On Tuesday, February 26, 2013 9:18:11 PM UTC-6, David DENG wrote:


    1. the processor (CPU) never reorders code, just pipeline or parallel
    at most
    2. the compiler may reorder (the generated code of) some statements
    only if,
    3. the generated code is logically equivallent to the original one

    These two statements are all wrong. The Alpha is notorious for reordering
    code, and on most CPUs loads and stores can complete after arithmetic
    operations
    that are dispached later. On some superscalar designs there is no global
    ordering of instructions, because each operational unit has its own queue
    of operations,
    and magic keeps the results consistent. Any CPU that does not have precise
    exceptions at all times does not have a concept of time in which
    instructions are externally
    visible or not depending on whether before or after a point in the
    instruction sequence, and most CPU architectures do not for increased
    performance.

    As for compilers, the real question is what is logically equivalent.
    Peterson's algorithm is not guarantied in Go to work.
    Hope this help.

    David
    On Tuesday, February 26, 2013 4:28:28 PM UTC+8, WENBO HUANG wrote:

    var c = make(chan int, 10)
    var a string

    func f() {
    a = "hello, world"
    c <- 0
    }

    func main() {
    go f()
    <-c
    print(a)
    }

    is guaranteed to print "hello, world". The write to a happens before
    the send on c, which happens before the corresponding receive on c completes,
    which happens before the print.


    "The write to a happens before the send on c", why processor is
    certainly not reordering it?
    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Bryanturley at Feb 27, 2013 at 4:40 am

    On Tuesday, February 26, 2013 9:55:15 PM UTC-6, David DENG wrote:
    1. Ok. Sorry for the first statement, I do not know much about different
    kinda CPUs . :-P. But CPU, in my mind, is always in the way I just
    mentioned. Only the writers of compiler has to make people like me happy
    even the CPU makes them unhappy.

    CPU makes everyone happy if it is fast. I am betting your cpu is mixing up
    your instructions as well
    http://en.wikipedia.org/wiki/Out_of_order_execution.
    I think the only common in-order cpus go (gc at least) supports are the
    older arms.
    Intel's Atom (everything but the newest models?) are in-order as well (from
    my memory, could be wrong)

    I am curious if anyone has go working on a system with less memory
    coherency than x86.

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.
  • Russ Cox at Feb 27, 2013 at 5:02 am
    The memory model specifies how a Go program must behave, regardless of what
    kind of CPU is being used.

    The details of what the CPU does and what it needs to be told to do or not
    to do are concerns for the Go implementation alone.

    Russ

    --
    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+unsubscribe@googlegroups.com.
    For more options, visit https://groups.google.com/groups/opt_out.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupgolang-nuts @
categoriesgo
postedFeb 26, '13 at 12:35p
activeFeb 27, '13 at 5:02a
posts22
users9
websitegolang.org

People

Translate

site design / logo © 2022 Grokbase