About C++ memory model and about Delphi and Freepascal..

[Horizon68]

Hello,


About C++ memory model and about Delphi and Freepascal..

The abstract machine in the C++98/C++03 specification is fundamentally
single-threaded. So it is not possible to write multi-threaded C++ code
that is "fully portable" with respect to the spec. The spec does not
even say anything about the atomicity of memory loads and stores or the
order in which loads and stores might happen.

Of course, you can write multi-threaded code in practice for particular
concrete systems – like pthreads or Windows. But there is no standard
way to write multi-threaded code for C++98/C++03.

The abstract machine in C++11 and above is multi-threaded by design. It
also has a well-defined memory model; that is, it says what the compiler
may and may not do when it comes to accessing memory.

The default mode for atomic loads/stores in C++11 and above is to
enforce sequential consistency. This just means all loads and stores
must be "as if" they happened in the order you wrote them within each
thread, while operations among threads can be interleaved however the
system likes. So the default behavior of atomics provides both atomicity
and ordering for loads and stores.

Now, on a modern CPU, ensuring sequential consistency can be expensive.
In particular, the compiler is likely to emit full-blown memory barriers
between every access here. But if your algorithm can tolerate
out-of-order loads and stores, you can use memory_order_relaxed.

So, bottom line. Mutexes are great, and C++11 standardizes them. But
sometimes for performance reasons you want lower-level primitives (e.g.,
the classic double-checked locking pattern). The new standard provides
high-level gadgets like mutexes and condition variables, and it also
provides low-level gadgets like atomic types and the various flavors of
memory barrier. So now you can write sophisticated, high-performance
concurrent routines entirely within the language specified by the
standard, and you can be certain your code will compile and run
unchanged on both today's systems and tomorrow's.

Although, unless you are an expert and working on some serious low-level
code, you should probably stick to mutexes and condition variables.

And now about Delphi and Freepascal(because as you have noticed i am
working with C++ and with Delphi and Freepascal)

As you have noticed i have invented many scalable algorithms and
there implementations, and they are now working on x86 architecture,
and even if Delphi and Freepascal have no memory model as the one of
C++11, i will soon make my scalable algorithms implementations in Delphi
and Freepascal and all my Delphi and Freepascal softwares "portable" by
first using a portable CLH lock that i will write in C and using it from
Delphi and Freepascal and second by using the functions of TInterlocked
class of Delphi and correspondent functions in Freepascal, and after
that all my Delphi and Freepascal projects will become portable on other
architectures than x86, and thus my Delphi and Freepascal scalable
algorithms implementations and all my Delphi and Freepascal softwares
will permit Delphi and Freepascal to become really much more capable and
powerful.

Here is my scalable algorithms that i have invented that i will make
portable:

- Scalable MLock
- Scalable AMLock
- Scalable SeqlockX
- Many kind of Scalable RWLocks that are starvation-free
- Scalable Asymmetric Reader-Writer Mutex that is starvation-free
- Scalable Rwlocks that are starvation-free using scalable counting networks
- Scalable Hashtable
- Scalable Parallel Varfiler
- Fully scalable Threadpool
- Scalable reference counting with efficient support for weak references
- Scalable FIFO queues both node-based and array-based
- ParallelFor() that scales very well.

You can find many of my scalable algorithms and there implementations
in C++ and Delphi and Freepascal on my following website:

https://sites.google.com/site/scalable68/



Thank you,
Amine Moulay Ramdane.

[Horizon68]

Hello...


Read this: