Hacker News Reader

Comment by steveklabnik | Hacker News Reader

I am woefully under-informed about the LKMM, but one useful comment I can contribute to this discussion is that the recommended strategy here would be extremely difficult to implement, because you can use both the relaxed and consume orderings in safe Rust today, and so making them unsafe would be a breaking change.

Furthermore, because they're standard library constructs, they are not straightforward to change in an edition either.

View on HN

If you wanted to do this, which to be clear I certainly don't think you should, the way to approach it would probably go like this:

1. Add new unsafe relaxed atomics features, by whatever means. Being new there's no backward compatibility worry.

2. Modify the existing safe atomics to treat Relaxed as Acquire-release. This doesn't break anything since Acquire-release is necessarily not breaking Relaxed guarantees, although of course some code now has worse performance than before.

Edited to add: Also, what do you mean you can use Consume today in Rust? Where? My std::sync::atomic::Ordering doesn't even list Consume as an option.

I was wrong about consume.

BTW, the likely reason is that newer C/C++ standards also include a warning that the "consume" memory ordering has unclear semantics and should not be used. It can be replaced by acquire which provides stronger guarantees.

> because they're standard library constructs

Not only "std library" (which is only available when an OS is used), but also "core library" constructs. That one is available completely independent of the OS. Which means also in the current Rust for Linux project, or any other bare-metal platform.

What the article suggests seems to be more along the lines of a clippy lint warning agaunst use of these orderings, which wouldn't be a breaking change.

I am vaguely uncomfortable with this idea for reasons I am struggling to put into words, but that is a more viable path, yeah.

Soft-deprecating something in the standard library with a clippy lint feels a bit off for me too; I think that if something in the standard library is going to be discouraged, it should be done in the standard library itself (e.g. through documentation and/or using the deprecation warning). Clippy is absolutely phenomenal, but I tend not to think of it as something that's intended to be required by all users. Using it as a way to keep track of discouraged std types feels like it could easily lead to fragmentation where users stop looking to the standard library as the source of truth for its own contents.

And after some period of that it could be made unsafe in a future edition. So it’s not a totally crazy idea, but the payoff would have to be quite something.

You cannot currently change the API of the standard library on a per-edition basis.

For most of the cases I use relaxed or have seen it being used, it seems to be a loss. It's often to e.g. increase some shared metric counters from multiple threads - where there's no real ordering concerns, and the only thing that matters is that it counts right and not when exactly he value gets visible. The cheapest possible atomic operation which can fulfill that use-case (relaxed) is fine there. Having to use `unsafe` for that doesn't seem too appealing.

> consume

How do you use the consume ordering in Rust today?

Whoops, just relaxed, I forgot about this!

Reply on news.ycombinator.com