Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.programming.threads > #4919
| 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 memory models... |
| Date | Fri, 1 Feb 2019 13:36:51 -0800 |
| Organization | A noiseless patient Spider |
| Lines | 74 |
| Message-ID | <q32e5j$uca$5@dont-email.me> (permalink) |
| Mime-Version | 1.0 |
| Content-Type | text/plain; charset=utf-8; format=flowed |
| Content-Transfer-Encoding | 7bit |
| Injection-Date | Fri, 1 Feb 2019 21:36:51 -0000 (UTC) |
| Injection-Info | reader02.eternal-september.org; posting-host="c7d4ee3d6fc9dd83babd175c1366110a"; logging-data="31114"; mail-complaints-to="abuse@eternal-september.org"; posting-account="U2FsdGVkX1/BMhwlYZO3w7GoLgZt/PNJk5G3Wr5rAiY=" |
| User-Agent | Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 |
| Cancel-Lock | sha1:wn3QtaNMYip0O2CkVTRTWLSJUcw= |
| Content-Language | en-US |
| X-Mozilla-News-Host | news://news.eternal-september.org:119 |
| Xref | csiph.com comp.programming.threads:4919 |
Show key headers only | View raw
Hello.. About memory models... I wrote about memory models, and i think that Delphi and FreePascal had the necessary to make it easier even if they have no memory model, here is the functions that you need: For Delphi there is a function called System.MemoryBarrier and here it is: http://docwiki.embarcadero.com/Libraries/Tokyo/en/System.MemoryBarrier And for FreePascal there three functions called: - ReadWriteBarrier - WriteBarrier - ReadBarrier Here they are: https://www.freepascal.org/docs-html/rtl/system/readwritebarrier.html So as you have noticed my scalable algorithms works on x86 , but with the above functions i will make them more easily portable to ARM and to other CPU architetures. And I have just taken a look at the following algorithm invented by Dmitry Vyukov: https://groups.google.com/forum/#!topic/lock-free/Hv3GUlccYTc Notice that it is using FlushProcessWriteBuffers() , and notice on the following what said Chris Thomasson about FlushProcessWriteBuffers() == Well, the thing with FlushProcessWriteBuffers() is that it will generate a lot of traffic in the sense of sending the interrupts to all the CPUS in the processes affinity mask. This is an "active" form of quiescent state auto-detection. As of now, vZOOM uses "passive" detection technique on Windows; It does not need to interrupt CPU activity. AFAICT, that is the only advantage I can see to passive epoch detection, rather than active. Also, for PDR, the epochs should be detected on a frequent enough basis to keep the deferred object lists from backing up too much. The frequency of epochs in an active system will be creating a lot of IPI traffic, while the passive system will be creating none. Read more here: https://groups.google.com/forum/#!topic/comp.programming.threads/E0gGTkg46HE == But I i have just invented a new scalable RWLock algorithm that is "better" than the above because it doesn't need FlushProcessWriteBuffers() and it doesn't use any membar or lock in the readers side and it is starvation-free and it is FIFO fair on the readers side and FIFO fair on the writers side, and i will implement my new scalable algorithm in C++ and Delphi and Freepascal. Thank youm Amine Moulay Ramdane.
Back to comp.programming.threads | Previous | Next | Find similar | Unroll thread
About memory models... Horizon68 <horizon@horizon.com> - 2019-02-01 13:36 -0800
csiph-web