Re: [fpc-pascal] Barriers semantics
Jonas Maebe via fpc-pascal wrote: See e.g. the explanation of "data dependency barrier" at https://www.sobyte.net/post/2022-08/cpu-cache-and-memory-barriers/ . In Interesting stuff to read. Regards, Adriaan van Os ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Barriers semantics
Jonas Maebe via fpc-pascal 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
Re: [fpc-pascal] Barriers semantics
On 14/08/2023 21:55, denisgolovan via fpc-pascal wrote: On 14/08/2023 18:19, denisgolovan via fpc-pascal wrote: 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. Again: Read, Write, ReadWrite and ReadDependency barrier _are_ common terms. However, they're computer architecture terms. When using these barrier functions, you should be familiar with memory models and memory ordering. Use higher level primitives if you want to reason using higher level concepts like acquire/release. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Barriers semantics
> 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
Re: [fpc-pascal] Barriers semantics
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. 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. Jonas ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org https://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
