Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #4883
| 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
About C++ memory model and about Delphi and Freepascal.. Horizon68 <horizon@horizon.com> - 2019-01-20 10:15 -0800
csiph-web