> On 14/08/2023 18:19, denisgolovan via fpc-pascal wrote:
>
>> Now we have "volatile" intrinsic for assignments in place, I'd like to ask
>> for another clarification.
>
> Just to make sure given your questions below: using volatile in the
> context of multithreaded code is completely wrong in 99.9% of the cases,
> and when it's not in the best case it's usually just highly inefficient.
> volatile in FPC/C++ is unrelated to volatile in Java or C# in that respect.
As long as volatile marks data access and but not field attribute - I am very
much fine with it.
Let Java/C# devs suffer it :)
>
>> Documentation states we have following barriers - ReadBarrier, WriteBarrier,
>> ReadDependencyBarrier, ReadWriteBarrier.
>>
>> I'd like to get an idea how those related to more common / standard terms -
>> Acquire/Release & their combinations?
>
> Read/Write barriers are terms used in cpu architecture manuals.
> Acquire/Release are high level parallel programming terms.
>
>> Is it safe to assume that:
>>
>> ReadBarrier - Acquire
>> WriteBarrier - Release
>> ReadWriteBarrier - Acquire+Release
>> ReadDependencyBarrier - which one is that?
>
> You cannot express a ReadDependencyBarrier in terms of acquire/release.
> See e.g. the explanation of "data dependency barrier" at
> https://www.sobyte.net/post/2022-08/cpu-cache-and-memory-barriers/ . In
> practice, I don't think any currently used cpu architectures still
> require such barriers though.
Ok. I assume I got it right.
This field lacks common terms for some reason.
-- Regards,
Denis Golovan
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
