[fpc-pascal] Barriers semantics

[Jonas Maebe]

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