I'm afraid your ideas about `volatile` with respect to multi-threading are about 14 years out of date. You're reading an object in one thread while it's being concurrently written in another, and it's not `std::atomic`. Since C++11, that's a data race and your program has undefined behavior. Under the standard, `volatile` doesn't save you; `std::atomic` is the only conformant way to do it. (And `std::atomic` does in fact achieve everything you want here; for instance, it inhibits optimizations like "read the value once and then never read it again.")

It's possible that your implementation provides some guarantees about `volatile` in multithreading beyond what the standard gives, but if so, that's between you and them; nothing to do with ISO C++.

Now, this doesn't directly answer your question about `volatile` on parameters and return types, but it does rather invalidate the use case you proposed.

The intended uses for `volatile` in this day and age are things like memory-mapped I/O, where your goal is to just make the machine perform a single load or store instruction. (Again, you may *think* that's exactly what you want for concurrent multithread access, but the standard doesn't promise that it will work.) So if you can propose an example of that kind, we could get back on track. However, for memory-mapped I/O, you almost never want to define an actual object of `volatile`-qualified type. You would work through pointers to such types, but the pointers themselves would not be `volatile`.

> On Nov 23, 2024, at 19:03, J Decker via Std-Discussion <std-discussion_at_[hidden]> wrote:
>
> https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1152r0.html#parret
>
>
> I have some datatype, which is a volatile list. What makes it volatile is that other threads can change the values associated with the list without any other threads being aware of the change. Primarily, what happens, when the objects are not defined as volatile, the optimizers can read the value early in a function, and then never read it again. The only meaning of volatile *I* knew of was 'read always'. Writes and locks and other unrelated things mentioned in the paper just confuse the issue. What I need is just a way to tell compiler optimizers 'hey don't be smart, if the code needs the value, get the value from the place specified.' Writes could be cached - but it's something the programmer would do. It(volatile) really has nothing to do atomics.