[fpc-pascal] Barriers semantics

[Sven Barth]

Jonas Maebe via fpc-pascal <fpc-pascal at lists.freepascal.org> schrieb am
Mo., 14. Aug. 2023, 21:02:

> 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.
>
> > 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.
>

Doesn't Aarch64 use acquire/release instructions for locking? 🤔


> > 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.
>

It depends on the use case. When working with external hardware onm Aarch64
(e.g. with DMA) they are very much a necessity.

Regards,
Sven

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freepascal.org/pipermail/fpc-pascal/attachments/20230815/7872668b/attachment.htm>