Jonas Maebe via fpc-pascal <fpc-pascal@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 >
_______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
