Re: [go-nuts] History & origins of the Go memory model

[Daniel Fava]

Thanks for this bit of history, Ian!  I’ve been studying the memory model in 
grad school for a few years now and I think it’s well written.  I was curious 
about how it came to be.

I think the “completes” also mater for buffered channels, for example:
https://github.com/golang/go/issues/37355 


Daniel


> On 27 Nov 2020, at 23:46, Ian Lance Taylor  wrote:
> 
> On Fri, Nov 27, 2020 at 12:57 PM Daniel Fava  wrote:
>> 
>> Does anyone know how the Go memory model came to be?  I don't have technical 
>> questions about it.  I just would like to know the historical context.
>> 
>> The model is specified in terms of happens-before, due to Lamport.  But the 
>> following rule, which allows channels to be used as locks, was not part of 
>> Lamport's original formulation:
>> 
>> "A receive from an unbuffered channel happens before the send on that 
>> channel completes. "
>> 
>> I'm curious who (if anyone) was involved in including this rule.  How did it 
>> come to be?
>> 
>> I also find it fascinating how the word "completes" seems to make a world of 
>> difference.  As I read it, removing the word "completes" from the rule above 
>> (and from the rule connecting a sender and its corresponding receiver 
>> receiver) would lead to a quite different memory model.  I'm curious how 
>> intentional the "completes" is.
> 
> As I recall, Tom Szymanski asked for the rules about when one
> goroutine would see changes made by another goroutine, and how that
> related to channel operations.  Russ Cox described what he thought
> should happen, Tom encouraged him to write that down, and Russ did,
> winding up with
> https://go.googlesource.com/go/+/82c38cf8dd628e6c90b6f1160be2a8d5088b77c9/doc/mem.html
> (when reading that doc, remember that it was written in February,
> 2009, and that the syntax has changed since then).
> 
> The "completes" is intentional.  A send/receive on an unbuffered
> channel was always intended to serve as a synchronization point
> between the goroutines.  Otherwise it would be hard for different
> goroutines to synchronize on anything.
> 
> Ian

-- 
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/569DA3B6-9D3E-4D4E-8F76-2F8ABF546AE4%40gmail.com.

Re: [go-nuts] History & origins of the Go memory model

[Ian Lance Taylor]

On Fri, Nov 27, 2020 at 12:57 PM Daniel Fava  wrote:
>
> Does anyone know how the Go memory model came to be?  I don't have technical 
> questions about it.  I just would like to know the historical context.
>
> The model is specified in terms of happens-before, due to Lamport.  But the 
> following rule, which allows channels to be used as locks, was not part of 
> Lamport's original formulation:
>
> "A receive from an unbuffered channel happens before the send on that channel 
> completes. "
>
> I'm curious who (if anyone) was involved in including this rule.  How did it 
> come to be?
>
> I also find it fascinating how the word "completes" seems to make a world of 
> difference.  As I read it, removing the word "completes" from the rule above 
> (and from the rule connecting a sender and its corresponding receiver 
> receiver) would lead to a quite different memory model.  I'm curious how 
> intentional the "completes" is.

As I recall, Tom Szymanski asked for the rules about when one
goroutine would see changes made by another goroutine, and how that
related to channel operations.  Russ Cox described what he thought
should happen, Tom encouraged him to write that down, and Russ did,
winding up with
https://go.googlesource.com/go/+/82c38cf8dd628e6c90b6f1160be2a8d5088b77c9/doc/mem.html
(when reading that doc, remember that it was written in February,
2009, and that the syntax has changed since then).

The "completes" is intentional.  A send/receive on an unbuffered
channel was always intended to serve as a synchronization point
between the goroutines.  Otherwise it would be hard for different
goroutines to synchronize on anything.

Ian

-- 
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/CAOyqgcXQcR7e0QU8rt4NbdLrqGtc92LzYPwWjyAs6u65C8dOUA%40mail.gmail.com.

[go-nuts] History & origins of the Go memory model

[Daniel Fava]

Hi,

Does anyone know how the Go memory model came to be?  I don't have 
technical questions about it.  I just would like to know the historical 
context.

The model is specified in terms of happens-before, due to Lamport.  But the 
following rule, which allows channels to be used as locks, was not part of 
Lamport's original formulation:

"A receive from an unbuffered channel happens before the send on that 
channel completes. "

I'm curious who (if anyone) was involved in including this rule.  How did 
it come to be?

I also find it fascinating how the word "completes" seems to make a world 
of difference.  As I read it, removing the word "completes" from the rule 
above (and from the rule connecting a sender and its corresponding receiver 
receiver) would lead to a quite different memory model.  I'm curious how 
intentional the "completes" is.

Thanks a lot!
Daniel

-- 
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/ea5f6db9-229b-49c0-a970-7a964d60577en%40googlegroups.com.