<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Jonas Maebe via fpc-pascal <<a href="mailto:fpc-pascal@lists.freepascal.org">fpc-pascal@lists.freepascal.org</a>> schrieb am Mo., 14. Aug. 2023, 21:02:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 14/08/2023 18:19, denisgolovan via fpc-pascal wrote:<br>
> Now we have "volatile" intrinsic for assignments in place, I'd like to ask for another clarification.<br>
<br>
Just to make sure given your questions below: using volatile in the <br>
context of multithreaded code is completely wrong in 99.9% of the cases, <br>
and when it's not in the best case it's usually just highly inefficient. <br>
volatile in FPC/C++ is unrelated to volatile in Java or C# in that respect.<br>
<br>
> Documentation states we have following barriers - ReadBarrier, WriteBarrier, ReadDependencyBarrier, ReadWriteBarrier.<br>
> <br>
> I'd like to get an idea how those related to more common / standard terms - Acquire/Release & their combinations?<br>
<br>
Read/Write barriers are terms used in cpu architecture manuals. <br>
Acquire/Release are high level parallel programming terms.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Doesn't Aarch64 use acquire/release instructions for locking? ðŸ¤” </div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> Is it safe to assume that:<br>
> <br>
> ReadBarrier - Acquire<br>
> WriteBarrier - Release<br>
> ReadWriteBarrier - Acquire+Release<br>
> ReadDependencyBarrier - which one is that?<br>
<br>
You cannot express a ReadDependencyBarrier in terms of acquire/release. <br>
See e.g. the explanation of "data dependency barrier" at <br>
<a href="https://www.sobyte.net/post/2022-08/cpu-cache-and-memory-barriers/" rel="noreferrer noreferrer" target="_blank">https://www.sobyte.net/post/2022-08/cpu-cache-and-memory-barriers/</a> . In <br>
practice, I don't think any currently used cpu architectures still <br>
require such barriers though.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">It depends on the use case. When working with external hardware onm Aarch64 (e.g. with DMA) they are very much a necessity. </div><div dir="auto"><br></div><div dir="auto">Regards, </div><div dir="auto">Sven </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
</blockquote></div></div></div>