| |
| Posted by claptrap in reply to max haughton | PermalinkReply |
|
claptrap
Posted in reply to max haughton
| On Saturday, 3 December 2022 at 03:42:01 UTC, max haughton wrote:
> On Wednesday, 30 November 2022 at 00:35:55 UTC, claptrap wrote:
>> On Wednesday, 30 November 2022 at 00:16:00 UTC, rikki cattermole wrote:
>>> On 30/11/2022 1:12 PM, H. S. Teoh wrote:
>>>> Hmm, that's weird that the docs would say that. I've always been under
>>>> the impression that core.atomic ops use locks to achieve atomicity.
>>>
>>> No its correct.
>>>
>>> As long as the hardware supports atomic operations, it'll use those instructions. It does have a fallback to use a mutex if need be though, which might be where you got that idea from.
>>
>> It really shouldn't do that IMO. People expect atomic ops to be lock-free, it should be compile error if it cant be so.
>
> I expect atomic ops to provide correct memory consistency, and preferably be atomic where the platform allows it.
I am really hoping that "preferably atomic" was just a poor choice or words.
I guess regarding the other issues I still think of atomic ops in terms of what the cpu does, so a high level wrapper around them that takes a lock is the complete antithesis to what is actually desired.
I mean the whole point of atomic ops is to be able to avoid using locks.
And if you look at the phobos docs...
"Atomically adds mod to the value referenced by val and returns the value val held previously. This operation is both lock-free and atomic."
https://dlang.org/library/core/atomic/atomic_fetch_add.html
|