| |
| Posted by max haughton in reply to claptrap | PermalinkReply |
|
max haughton
Posted in reply to claptrap
| On Sunday, 4 December 2022 at 10:15:48 UTC, claptrap wrote:
> On Sunday, 4 December 2022 at 01:51:56 UTC, max haughton wrote:
>> On Saturday, 3 December 2022 at 21:05:51 UTC, claptrap wrote:
>>> On Saturday, 3 December 2022 at 20:18:07 UTC, max haughton wrote:
>>>> On Saturday, 3 December 2022 at 13:05:44 UTC, claptrap wrote:
>>>>> [...]
>>>>
>>>> If it provides the same memory ordering guarantees does it matter (if we ignore performance for a second)? There are situations where you do (for reasons beyond performance) actually need a efficient (no overhead) atomic operation in lock-free coding, but these are really on the edge of what can be considered guaranteed by any specification.
>>>
>>> It matters because the whole point of atomic operations is lock free coding. There is no oh you might need atomic for lock free coding, you literally have to have them. If they fall back on a mutex it's not lock free anymore.
>>>
>>> memory ordering is a somewhat orthogonal issue from atomic ops.
>>
>> Memory ordering is literally why modern atomic operations exist. That's why there's a lock prefix on the instruction in X86 - it doesn't just say "do this in one go" it says "do this in one go *and* maintain this memory ordering for the other threads".
>
> No it's not, literally go read the Intel SDM, the lock prefix is for atomic operations, that's it's intent. That it also has extra memory ordering guarantees between cores is simply because it would be useless if it didn't also do that.
>
> The m/s/l/fence instructions are for memory ordering.
>
> If you still dont believe me consider this. x86 has always had strong memory ordering, there's no need to worry about reads to a given location being moved ahead of writes to the same location if you are on a single core. That only goes out of the window when you have a multicore x86. The lock prefix existed before x86 cpus had multiple cores. IE locked instructions are for atomics, the memory ordering guarantees already existed for all reads/writes on single cores. The extra guarantees for memory ordering between cores were added when x86 went multicore, because lock free algorithms would not work if the atomic reads/writes were not also ordered between cores.
>
> To say atmoics are about memory ordering is like saying cars are for parking. Yes you have to park them somewhere, but thats not the problem they are meant to solve.
X86 isn't the only processor, by atomics I am referring to the ones we use in programming languages (note that I said modern). The ones in D are basically inherited from C++11 (and LLVM), and we're drafted because working with memory ordering prior to them was wild-west.
X86 is also still ordered with or without a LOCK prefix. It's a weaker kind of order but it's still defined (it actually wasn't defined to an academically satisfactorily standard until shockingly recently). For example, a store with release ordering on X86 will yield a regular mov instruction.
|