Why isn't the memory model part of the spec?

[will....@gmail.com]

It seems required to understand how Go programs work.

If the memory model was never written, or is omitted from an implementation, would the concurrency features still be reliable and useful?

[Kurtis Rader]

On Wed, Oct 9, 2024 at 11:30 PM will....@gmail.com <will....@gmail.com> wrote:

It seems required to understand how Go programs work.

If the memory model was never written, or is omitted from an implementation, would the concurrency features still be reliable and useful?

The memory model is part of the Go specification. See https://go.dev/ref/mem. You seem to expect that considerations of the memory model employed by Go be fully documented in the https://go.dev/ref/spec document. That is reasonable but not the only way to document that information.

If the memory model was not documented the Go concurrency features would not be reliable. But the memory model expected by the Go language is documented. So it's not clear what you are asking.  Are you asking if the designers of Go had not considered, and documented, the importance of a memory model would Go still be a useful language for concurrent programming? It seems to me the answer is, no. But that seems to be a self evident question.

--

Kurtis Rader

Caretaker of the exceptional canines Junior and Hank

[Marvin Renich]

* Kurtis Rader <kra...@skepticism.us> [241010 03:05]:

> On Wed, Oct 9, 2024 at 11:30 PM will....@gmail.com <will....@gmail.com>
> wrote:
>
> > It seems required to understand how Go programs work.
> >
> > If the memory model was never written, or is omitted from an
> > implementation, would the concurrency features still be reliable and useful?
> >
>
> The memory model is part of the Go specification. See https://go.dev/ref/mem.
> You seem to expect that considerations of the memory model employed by Go
> be fully documented in the https://go.dev/ref/spec document. That is
> reasonable but not the only way to document that information.

I agree with you, but I also think it would be reasonable to expect the
Language Spec document to have an explicit reference to the Memory Model
document, probably in the introduction.

...Marvin

[Ian Lance Taylor]

On Wed, Oct 9, 2024 at 11:30 PM will....@gmail.com
<will....@gmail.com> wrote:
>

People were able to write concurrent Go code successfully for years
before the memory model was written. As it says right at the start of
the memory model reference: "If you must read the rest of this
document to understand the behavior of your program, you are being too
clever." Yes, you do have to understand channels and mutexes in order
to write concurrent code, but they are reasonably simple to understand
and to use correctly. In fact, I think people understand and use them
correctly without ever reading or understanding the details of the
memory model.

I'm glad that we do have a memory model, but I really don't think it's
necessary reading for the most Go programmers. The spec, on the other
hand, is intended to be readable and useful for all Go programmers.

Ian

[Robert Engels]

The memory model is very important when writing lock free concurrent structures - especially cross platform.

It “worked” because the behavior was what most people would expect but I suspect there were lots of good around making it work and verifying when porting to different architectures.

> On Oct 10, 2024, at 11:27 AM, Ian Lance Taylor <ia...@golang.org> wrote:
>
> On Wed, Oct 9, 2024 at 11:30 PM will....@gmail.com

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

[Kurtis Rader]

On Wed, Oct 9, 2024 at 11:30 PM will....@gmail.com <will....@gmail.com> wrote:

It seems required to understand how Go programs work.

If the memory model was never written, or is omitted from an implementation, would the concurrency features still be reliable and useful?

In addition to Ian's reply that people successfully wrote concurrent Go code before the memory model document was published It is, perhaps, also worth noting that not every computer architecture behaves the same way vis-a-vis memory access. I'm a grey beard who started programming in 1977. I've programmed on computers with a 

*) 24 bit word size (the Harris "H" series, https://en.wikipedia.org/wiki/Harris_Computer_Systems)

*) 36 bit word size (the Honeywell 6000 series)

*) 60 bit word size (the CDC Cyber 760 which also used ones-complement for integers)

*) 32/64 bit word size architectures that are now commonplace

More relevant is my experience programming (as a customer and then an employee) of Sequent Computer Systems SMP and NUMA architecture systems. The memory model of the Sequent "Balance" line that used National Semiconductor NS32032 processors was different from that of the Sequent "Symmetry" line which used Intel x86 processors. The high-level abstractions provided by Go's channels and mutexes make it relatively easy to write reliable, portable, code that would work on those very different computer architectures. You only need to know the details of the memory model employed by Go if you are writing code that implements similar abstractions for the hardware architecture.