Skip to content

langref: describe memory model and atomic orders#22507

Open
tau-dev wants to merge 1 commit intoziglang:masterfrom
tau-dev:langref
Open

langref: describe memory model and atomic orders#22507
tau-dev wants to merge 1 commit intoziglang:masterfrom
tau-dev:langref

Conversation

@tau-dev
Copy link
Copy Markdown
Contributor

@tau-dev tau-dev commented Jan 16, 2025

EDIT: Some motivation:
The point of a reference is to describe the language succinctly and accurately, without saying only "go read the formal specification". LLVM's description of the memory model, which we are currently linking to, is verbose and scattered over multiple pages. The description in this PR is more structured and much more concise, without any oversimplification.

@Rexicon226
Copy link
Copy Markdown
Contributor

I'm not a core member, but I would like to add my two cents. This is a very sensitive topic that requires an extremely rigorous definition, which the cppreference already provides. In my experience, trying to "simplify" the definition creates certain inconsistencies and should be reserved for blog posts and articles, not language references.

@alexrp
Copy link
Copy Markdown
Member

alexrp commented Jan 16, 2025

Yeah, I'm not too keen on trying to specify the (frankly very complicated) C++ memory model in the language reference, especially when we don't yet know if Zig will actually keep this memory model for the long term. Even Rust doesn't try to do this.

IMO, what we should do is simply state that Zig currently inherits the LLVM/C++11 memory model, but that this may change before 1.0. For each type of memory ordering, we could link to the relevant LLVM documentation section and cppreference section, and leave it at that.

@tau-dev
Copy link
Copy Markdown
Contributor Author

tau-dev commented Jan 16, 2025

I think the language reference should stand on its own and provide a decent description even for features that are currently implemented by a dependency, particularly as we are gaining backends that do not use the LLVM dependency.

Note that the memory model of C and C++ is significantly more subtle than that of LLVM, so the comparison to cppreference is largely irrelevant. In particular, C/C++ have the notion of consume, which Clang just treats as the simpler acquire. I believe I have not modified the meaning of LLVM's definitions nor omitted important information.

Comment thread doc/langref.html.in
Zig currently inherits LLVM's memory model, but <a href="https://github.com/ziglang/zig/issues/6396">may
define its own one</a> (most likely compatible with LLVM). Until then,
<a href="https://llvm.org/docs/LangRef.html#memory-model-for-concurrent-operations">LLVM's documentation</a> is
the ground truth.
Copy link
Copy Markdown

@zxubian zxubian Jan 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not a core member, but here's my 2 cents:

I think that lines 4040~4212 are a concise way of explaining the status quo while providing further references 👍

I'd say that everything below line 4212 is excessive for this PR.

  • The text as is attempts to give an introductory overview of motivation behind memory consistency models without rigorously defining any particular one. However, I believe the language reference is not the correct place to learn about memory models in general.
  • Attempting to rigorously define the LLVM memory model surely would also be outside the scope of Zig's langref.

So, I'd argue that the best thing Zig can do right now is exactly captured in lines 4040~4212 of this PR: explain the status quo, reference LLVM, and note that things might change.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The point of a reference is to describe the language accurately, without saying only "go read the formal specification". Why should this principle not apply to the section on multithreading?

@alexrp
Copy link
Copy Markdown
Member

alexrp commented Jan 18, 2025

I think the language reference should stand on its own and provide a decent description even for features that are currently implemented by a dependency

I'm not sure I buy this argument. What about e.g. floating point semantics? Where would we draw the line?

I think it's fine to reference a third-party spec when the Zig language is just providing an implementation of that spec, as opposed to actually defining it authoritatively.

@tau-dev
Copy link
Copy Markdown
Contributor Author

tau-dev commented Jan 18, 2025

The cppreference, the Rust std docs and the Nomicon describe the memory model but not IEEE754 floats.

IEEE754 has become a de-facto standard for most high- and low-level programming languages in use today, while the majority of languages out there do not expose a memory model of "just what LLVM does".

Also note that the language reference isn't defining anything authoritatively. That will be the job of the specification, which will define the memory model formally—or defer to LLVM—for implementers and tool authors. The reference should give common users a precise but fast-to-acquire understanding of the language, and I believe LLVM's specification is too formal and scattered to do that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants