Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2023-08

Barriers semantics

6 messages · 4 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

denisgolovan

Hi all

Now we have "volatile" intrinsic for assignments in place, I'd like to ask for another clarification. 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? Is it safe to assume that:

ReadBarrier - Acquire
WriteBarrier - Release
ReadWriteBarrier - Acquire+Release
ReadDependencyBarrier - which one is that?

-- Regards,
Denis Golovan

Jonas Maebe
to denisgolovan
denisgolovan 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.

Show quoted text 6 lines
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

denisgolovan
to Jonas Maebe
Show quoted text 8 lines
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 :)

Show quoted text 20 lines
> 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

Jonas Maebe
to denisgolovan
denisgolovan wrote 13 lines
> 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

Sven Barth
to Jonas Maebe: Just to make sure given your questions below: using volatile in the context of…

Jonas Maebe via fpc-pascal schrieb am
Mo., 14. Aug. 2023, 21:02:

Show quoted text 18 lines
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? 🤔

Show quoted text 13 lines
> 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