Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.programming.threads > #4883

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

Path csiph.com!eternal-september.org!feeder.eternal-september.org!reader01.eternal-september.org!.POSTED!not-for-mail
From Horizon68 <horizon@horizon.com>
Newsgroups comp.programming.threads
Subject About C++ memory model and about Delphi and Freepascal..
Date Sun, 20 Jan 2019 10:15:13 -0800
Organization A noiseless patient Spider
Lines 86
Message-ID <q22drh$5ds$3@dont-email.me> (permalink)
Mime-Version 1.0
Content-Type text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding 8bit
Injection-Date Sun, 20 Jan 2019 18:15:13 -0000 (UTC)
Injection-Info reader02.eternal-september.org; posting-host="acb0d5e10a2f543e302b5f12815aebd8"; logging-data="5564"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX188DQ038EtnyN9DVSA5LgTJtg6X4OYVMGs="
User-Agent Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
Cancel-Lock sha1:Kiulgh39dy0SAft4ZkEKoXTF2jQ=
Content-Language en-US
X-Mozilla-News-Host news://news.eternal-september.org:119
Xref csiph.com comp.programming.threads:4883

Show key headers only | View raw


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.

Back to comp.programming.threads | Previous | Next | Find similar | Unroll thread


Thread

About C++ memory model and about Delphi and Freepascal.. Horizon68 <horizon@horizon.com> - 2019-01-20 10:15 -0800

csiph-web