I have just read this about the C++11 Memory Model

[Ramine]

Hello,


I have just read this about the C++11 Memory Model:

Some programming languages offer SC in multiprocessor environment. In
C++11, you can declare all shared variables as C++11 atomic types with
default memory ordering constraints. In Java, you can mark all shared
variables as volatile [1] [2].

Because the C++11 atomic types guarantee sequential consistency, the
outcome r1 = r2 = 0 is impossible. To achieve this, the compiler outputs
additional instructions behind the scenes – typically memory fences
and/or RMW operations. Those additional instructions may make the
implementation less efficient compared to one where the programmer has
dealt with memory ordering directly.

Read here:

https://people.cs.pitt.edu/~xianeizhang/notes/cpp11_mem.html

So, there is still a problem with C++, because so it is still error
prone if you forget C++11 atomic types to ensure sequential consistency
and it is less efficient with atomic types.


So i still prefer Delphi and FreePascal that don't reorder loads and stores.



Thank you,
Amine Moulay Ramdane.

[Rick C. Hodgin]

On Saturday, March 18, 2017 at 10:44:35 PM UTC-4, Ramine wrote:
> Hello...

You are unique, Ramine. I have prayed for you.

Thank you,
Rick C. Hodgin

[Chris Vine]

On Sat, 18 Mar 2017 22:44:26 -0400
Ramine <to...@toto.net> wrote:
> I have just read this about the C++11 Memory Model:
>
> Some programming languages offer SC in multiprocessor environment. In
> C++11, you can declare all shared variables as C++11 atomic types
> with default memory ordering constraints. In Java, you can mark all
> shared variables as volatile [1] [2].
>
> Because the C++11 atomic types guarantee sequential consistency, the
> outcome r1 = r2 = 0 is impossible. To achieve this, the compiler
> outputs additional instructions behind the scenes – typically memory
> fences and/or RMW operations. Those additional instructions may make
> the implementation less efficient compared to one where the
> programmer has dealt with memory ordering directly.
>
> Read here:
>
> https://people.cs.pitt.edu/~xianeizhang/notes/cpp11_mem.html
>
> So, there is still a problem with C++, because so it is still error
> prone if you forget C++11 atomic types to ensure sequential
> consistency and it is less efficient with atomic types.

That's wrong, in C++ atomics are not less efficient. To achieve full
sequential consistency any language would use the same processor
instructions to achieve that (usually, an MFENCE barrier on x86/64).
And if you forget to use the correct types in any language, or fail to
synchronize correctly, your program will fail.

> So i still prefer Delphi and FreePascal that don't reorder loads and
> stores.

You are very naive. Of course the Delphi compiler reorders loads and
stores, or it couldn't optimize, and it may indeed eliminate some of
them entirely; and even if the Delphi compiler does not, the hardware
might. What you probably mean is that the Delphi compiler does not
reorder loads and stores when optimizing so as to violate its execution
ordering guarantees. Neither does C++ with respect to its memory model,
including its default of sequential consistency. The C++ memory model
forbids compilers optimizing in a way which violates it. There are all
sorts of optimizations a compiler can carry out on single threaded code
that it cannot carry out on multi-threaded code.

I say "probably" above because I do not think you understand how to
program properly in Delphi either. You need to synchronize Delphi code
when using multiple threads, just as you need to synchronize C++ code
when using multiple threads.

[Ramine]

This is not my fault, delphi and freepascal has not inform us on that,
so i have just read on internet and that was not sufficient,
so i think that Delphi and FreePascal can reorder loads and stores,
so what i must do now is use the syncobjs unit to be able to
synchronize correctly and be sequential consistent:

Here it is:

http://www.freepascal.org/docs-html/3.0.0/fcl/syncobjs/tcriticalsection.html


So i will update all my projects soon.

[Ramine]

On 3/19/2017 9:00 AM, Chris Vine wrote:

This is not my fault, delphi and freepascal have not inform us on that,

so i have just read on internet and that was not sufficient,
so i think that Delphi and FreePascal can reorder loads and stores,
so what i must do now is use the syncobjs unit to be able to
synchronize correctly and be sequential consistent:

Here it is:

http://www.freepascal.org/docs-html/3.0.0/fcl/syncobjs/tcriticalsection.html


So i will update all my projects soon.

[Chris Vine]

On Sun, 19 Mar 2017 09:37:29 -0400
Ramine <to...@toto.net> wrote:
> On 3/19/2017 9:00 AM, Chris Vine wrote:

[snip]

> > You are very naive. Of course the Delphi compiler reorders loads
> > and stores, or it couldn't optimize, and it may indeed eliminate
> > some of them entirely; and even if the Delphi compiler does not,
> > the hardware might. What you probably mean is that the Delphi
> > compiler does not reorder loads and stores when optimizing so as to
> > violate its execution ordering guarantees. Neither does C++ with
> > respect to its memory model, including its default of sequential
> > consistency. The C++ memory model forbids compilers optimizing in
> > a way which violates it. There are all sorts of optimizations a
> > compiler can carry out on single threaded code that it cannot carry
> > out on multi-threaded code.
> >
> > I say "probably" above because I do not think you understand how to
> > program properly in Delphi either. You need to synchronize Delphi
> > code when using multiple threads, just as you need to synchronize
> > C++ code when using multiple threads.
>
> This is not my fault, delphi and freepascal has not inform us on that,
> so i have just read on internet and that was not sufficient,
> so i think that Delphi and FreePascal can reorder loads and stores,
> so what i must do now is use the syncobjs unit to be able to
> synchronize correctly and be sequential consistent:

I think the problem is that you are very naive and confused.
Synchronizing multiple threads correctly is not just about how the
compiler optimizes: that is a necessary but very small part of it. You
cannot guarantee the ordering of memory operations between threads just
by turning compiler optimizations off.

Synchronization goes to the hardware level. The only way two or more
threads running on different cores on modern hardware can be guaranteed
to see the same values in memory at any given time and the same
modification order of different memory locations is by having the
compiler issue the correct processor instructions to procure this. One
way of having the compiler do this is to use mutexes, which
automatically synchronize. Another way of doing it is to use atomic
variables with the correct memory ordering.

No language provides or can provide short cuts for this.

[Ramine]

What i am saying that TCriticalSection of Delphi and FreePascal
ensures that all is correct, but if you want to code
my MLock or my AMLock algorithms you have to use C++, because Delphi and
FreePascal can reorder loads and stores and you can not do anything
about it.

But that's easy in FreePascal and Delphi , i will just
use TCriticalSection of syncobjs unit, and i will use a Mutex
on Windows and Linux provided by the FreePascal compiler on Windows
and Linux..


So i will update soon my projects.

[Ramine]

On 3/19/2017 9:54 AM, Chris Vine wrote:

And i think i will code my MLock and AMlock algorithms with C++
and C++ atomic types, because they can not be implemented with Delhi
or FreePascal.


Thank you,
Amine Moulay Ramdane,.

[Chris Vine]

On Sun, 19 Mar 2017 10:09:46 -0400
Ramine <to...@toto.net> wrote:
[snip]

> What i am saying that TCriticalSection of Delphi and FreePascal
> ensures that all is correct, but if you want to code
> my MLock or my AMLock algorithms you have to use C++, because Delphi
> and FreePascal can reorder loads and stores and you can not do
> anything about it.

You still don't understand. It is not just about the reordering of
loads and stores (which you could deal with by switching optimization
off). It is a question of procuring synchronization in the hardware
itself. If Delphi only provides mutexes/critical sections to do this,
and you want to use atomic variables for efficiency reasons, then yes
you need to use a better language.

[Ramine]

On 3/19/2017 10:17 AM, Chris Vine wrote:
> On Sun, 19 Mar 2017 10:09:46 -0400
> Ramine <to...@toto.net> wrote:
> [snip]
>> What i am saying that TCriticalSection of Delphi and FreePascal
>> ensures that all is correct, but if you want to code
>> my MLock or my AMLock algorithms you have to use C++, because Delphi
>> and FreePascal can reorder loads and stores and you can not do
>> anything about it.
>
> You still don't understand. It is not just about the reordering of
> loads and stores (which you could deal with by switching optimization
> off). It is a question of procuring synchronization in the hardware
> itself.

What i have said is that mutex and TCriticalsection of Delphi and
FreePascal provide that.

If Delphi only provides mutexes/critical sections to do this,
> and you want to use atomic variables for efficiency reasons, then yes
> you need to use a better language.
>

And i think i will code my MLock and AMlock algorithms with C++

and C++ atomic types, because they can not be implemented with Delphi
or FreePascal, i know that you can switch optimization off to avoid
memory reordering , but i don't like this way.

[Ramine]

Here is what i will do:

I will set optimization off in the source code of MLock and AMLock
and the TicketSpinlock with a proportional back-off:


by using this in FreePascal:

{$OPTIMIZATION ON}

http://www.freepascal.org/docs-html/prog/progsu58.html

and by using this in Delphi:

{$O-}

http://docwiki.embarcadero.com/RADStudio/Seattle/en/Optimization_(Delphi)


This way is easy, so i will updated my projects soon.

That's all,
Amine Moulay Ramdane.

[Ramine]

On 3/19/2017 10:17 AM, Chris Vine wrote:

[Ramine]

On 3/19/2017 10:17 AM, Chris Vine wrote:

Sorry i correct:

Here is what i will do:

I will set optimization off in the source code of MLock and AMLock
and the TicketSpinlock with a proportional back-off:


by using this in FreePascal:

{$OPTIMIZATION OFF}

[Chris Vine]

On Sun, 19 Mar 2017 10:28:39 -0400
Ramine <to...@toto.net> wrote:
[snip]

> Here is what i will do:
>
> I will set optimization off in the source code of MLock and AMLock
> and the TicketSpinlock with a proportional back-off:
>
>
> by using this in FreePascal:
>
> {$OPTIMIZATION ON}
>
> http://www.freepascal.org/docs-html/prog/progsu58.html
>
> and by using this in Delphi:
>
> {$O-}
>
> http://docwiki.embarcadero.com/RADStudio/Seattle/en/Optimization_(Delphi)
>
>
> This way is easy, so i will updated my projects soon.

I have now explained the problem to you three times and you are _still_
too obtuse to understand it.

On multi-core machines switching off optimization WOULD NOT WORK,
because there is NO SYNCHRONIZATION. The problem is not just one of
reordering loads and stores.

Please stop publicizing your code, and posting on this newsgroup, until
you have acquired the minimum knowledge to qualify you to do so. You
are a walking disaster area.

[Ramine]

You don't understand, i was aware that memory ordering is not the only
issue and that you have to use fences and atomics etc. but
what i am explaining to you is that my implementation of my algorithms
like my MLock and AMLock etc. already uses the correct fences to ensure
sequential consistency in the hardwre side, but what i need is to switch
the optimization off to avoid memory ordering
of the Delphi and FreePascal compilers.


Thank you,
Amine Moulay Ramdne.

[Jerry Stuckle]

On 3/19/2017 10:40 AM, Chris Vine wrote:

Chris, I suggest you give it up. You would have better luck teaching
quantum physics to a pet rock (which is more intelligent than Ramine).

Ramine is a moron (as well as a sexist pig) who already knows everything.

--
==================
Remove the "x" from my email address
Jerry Stuckle
jstu...@attglobal.net
==================

[Ramine]

On 3/19/2017 10:40 AM, Chris Vine wrote:

Read again..

You don't understand, i was aware that memory ordering is not the only
issue and that you have to use fences and atomics etc. but
what i am explaining to you is that my implementation of my algorithms
like my MLock and AMLock etc. already uses the correct fences to ensure

sequential consistency in the hardware side, but what i need is to

[Ramine]

[Chris Vine]

On Sun, 19 Mar 2017 10:50:04 -0400
Ramine <to...@toto.net> wrote:
[snip]

> You don't understand, i was aware that memory ordering is not the
> only issue and that you have to use fences and atomics etc. but
> what i am explaining to you is that my implementation of my
> algorithms like my MLock and AMLock etc. already uses the correct
> fences to ensure sequential consistency in the hardwre side, but what
> i need is to switch the optimization off to avoid memory ordering
> of the Delphi and FreePascal compilers.

In which case your original post which began this latest run of posts
was complete nonsense. If you have inserted your own fences at the
assembly level in your code and were relying on a (non-existent) no
reordering guarantee by Delphi for the rest, then you could not
possibly have come to the conclusion that this was less error prone or
more efficient than using C++ atomic variables, which do all of that
for you. (This includes acting as a compiler barrier to prevent
reordering around the atomic variable.)

So I repeat, please stop posting your opinions to this newsgroup until
you have acquired the minimum level of knowledge to qualify you to do
so. Until then, restrict yourself to questions about C++ only, and do
so without the perpetual repetition.

[Jerry Stuckle]

I don't need to read anything again. You have repeatedly proven
yourself to be a sexist pig. And I apologize to all morons for calling
you a moron. You don't rate that high.

[Chris M. Thomasson]

Why not just "bite the bullet", and use a language that allows for an
efficient use of the low-level primitives you are looking for?

Fwiw, back in the day, when this type of stuff was not standard in
C/C++, I had to create my own little abstractions via assembly language
to get things to "work", using PThreads. Even then, disabling link-time
optimizations for such highly sensitive constructs was considered
prudent, afraid it can possibly screw up ones custom sync code. Here is
an example:

https://groups.google.com/forum/#!msg/comp.programming.threads/KepRbFWBJA4/pg83oJTzPUIJ
(read entire thread, I am SenderX... ;^)

http://webpages.charter.net/appcore/appcore/src/cpu/i686/ac_i686_masm_asm.html

Now, C and C++ have standard memory order semantics, and various atomic
types. We can build many things that take advantage of these primitives.
So, basically, this custom asm code I created, is not really needed
anymore. Now, at least its standard in the language as-is: Thank God!

On a side note, I do not have access to C11 threading primitives in my
compiler base, but C++ works like a charm...

;^)


Also, read the posts created by Chris Vine over and over again, at least
41, perhaps even 42 times...

[Chris M. Thomasson]

Spot on Chris Vine! :^D