Wednesday, May 11, 2016

Digest for comp.programming.threads@googlegroups.com - 21 updates in 10 topics

bleachbot <bleachbot@httrack.com>: May 10 09:14PM +0200

bleachbot <bleachbot@httrack.com>: May 10 09:36PM +0200

bleachbot <bleachbot@httrack.com>: May 10 10:05PM +0200

bleachbot <bleachbot@httrack.com>: May 10 10:49PM +0200

bleachbot <bleachbot@httrack.com>: May 11 03:30AM +0200

bleachbot <bleachbot@httrack.com>: May 11 03:38AM +0200

bleachbot <bleachbot@httrack.com>: May 11 03:51AM +0200

bleachbot <bleachbot@httrack.com>: May 11 04:05AM +0200

bleachbot <bleachbot@httrack.com>: May 11 04:09AM +0200

bleachbot <bleachbot@httrack.com>: May 11 04:39AM +0200

Ramine <ramine@1.1>: May 10 10:40PM -0700

Hello....
 
Here is my final words about C++
 
As you have noticed i have implemented my great C++ synchronization
objcts library, but i must be frank, this is my last contribution to
C++, because C and C++ are dangerous beasts, since there memory model
is weaker and weaker than the Strong Memory Model of the x86
architecture , so from now on i will stop writing in C++.
 
This was my last post on this C++ group.
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 10 10:10PM -0700

Hello,
 
I must be more clearer...
 
C++ and C and Java have weaker memory model than the x86 architecture
strong memory model, and that's error prone and not safe, because the
way of thinking of C and C++ is a more optimization way of thinking,
this is why i think that's dangerous, i think if i want to follow the
Spirit of Spark, i must say that since FreePascal and Delphi don't
reorder loads and stores on x86 , so that's make the life easier for us
on x86 , since that makes the reasoning easier for sequential
consistency etc.
 
 
This is why i don't like C or C++.
 
 
Thank you,
Amine Moulay Ramdane
Ramine <ramine@1.1>: May 10 10:06PM -0700

Hello....
 
I must be more clearer...
 
C++ and C and Java have weaker memory model than the x86 architecture
strong memory model, and that's error prone and not safe, because the
way of thinking of C and C++ is a more optimization way of thinking,
this is why i think that's dangerous, i think of i want to follow the
Spirit of Spark i must say that since FreePascal and Delphi don't
reorder loads and stores on x86 , so that's make the life easier for us
on x86 , since that makes the reasonning easier for sequential
consistency etc.
 
 
This is why i don't like C or C++.
 
 
Thank you,
Amine Moulay Ramdane,.
Ramine <ramine@1.1>: May 10 09:52PM -0700

Hello...
 
I must be clear about an important think about C++..
 
Since C++ follow a weak memory model , i really think
that C++ is not safe, because this weak memory model is
error prone , and this is very dangerous, this
is why i am compiling my Dynamic Link Libraries with
FreePascal that doesn't reorder loads and stores and
that's more safe than C++.
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 10 09:30PM -0700

Hello.....
 
I have wrote this:
 
>this is why the windows function FlushProcessWriteBuffers() is needed
>in the writer side of my scalable Asymmetric reader-writer mutex
>algorithms.
 
And Chris Vin responded to me this:
 
 
>I would be very surprised if this doesn't affect all your code in other
>ways, because your posting shows that you don't understand the basics
>and are therefore clueless.
 
 
I think that Chris Vine doesn't understand my way of thinking,
your way of thinking is an optimization way of thinking that is
error prone, but me, i am adopting the ADA and the Spark
way of thinking and using a Full memory barrier to
reduce the risk of errors, on x86 an Mfence is 400 CPU cycles
and an Sfence is 200 CPU cycles , so to be more safe we can
also always use an Mfence and that's not a big difference i think.
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 10 09:38PM -0700

Hello,
 
I am speaking from a Delphi and FreePascal point of view,
because i am compiling my Dynamic Link Libraries with
FreePascal or Delphi and using them in C++.
 
 
 
Thank you,
Amine Moulay Ramdane.
aminer68@gmail.com: May 10 05:05PM -0700

Hello,
 
Finally my great updated C++ synchronization objects library is here...
 
I have corrected the bug with my scalable Asymmetric Distributed Reader-Writer mutex , and now i have modified some logic inside it, and now
it uses the windows FlushProcessWriteBuffers() on the writer side of my algorithm that executes a Full memory barrier on the other processors so that the variables that are needed by the writer side of my algorithm are visible. So you have to understand that declaring a variable volatile in C++ is not a sufficient condition to make the variable visible across cores, you need to execute a Full memory barrier, and this is what is doing the windows function FlushProcessWriteBuffers() on the writer side of my algorithm.
 
 
Now i need to make my new scalable Asymmetric Distributed Reader-Writer Mutex algorithm more clear, the Dmitry Vyukov scalable Asymmetric rw_mutex here:
 
https://groups.google.com/forum/#!topic/lock-free/Hv3GUlccYTc
 
This algorithm when it makes "writer_pending = true", it will block
all the readers the time needed for the following loop to execute:
 
for (int i = 0; i != max_reader_count; ++i)
{
// wait for all readers to complete
while (reader_inside[i])
SwitchToThread();
}
 
 
An this is expensive and not efficient, but my new algorithm that
is my scalable Asymmetric Distributed Reader-Writer Mutex algorithm,
doesn't block like that the reader threads, since in my new algorithm even if you enter like this loop above, the reader-side can still execute in parallel when the loop is not yet finished,
and this what makes my scalable Asymmetric Distributed Reader-Writer Mutex algorithm efficient, it has more parallelism than the Dmitry Vyukov scalable Asymmetric rw_mutex.
 
 
If you need to take a look at my new algorithm, just download the
source code , just look at version 2 of my algorithm
inside DRWLOCK.pas source code, you can download the source code
from here:
 
https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex
 
So hope that you will be happy with my great C++ synchronization objects library !
 
 
You can download my new and updated C++ synchronization objects library
from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 10 04:49PM -0700

Hello...
 
Parallel programming is not so difficult, you have just to know some
rules of parallel programming, i have just verified my algorithm of my
scalable Asymmetric Distributed reader-writer mutex and the only thing
that i need is the windows FlushProcessWriteBuffers() on the writer
side, i have just verified the logic and FlushProcessWriteBuffers() will
solve the problem, but in my other algorithms i don't need
FlushProcessWriteBuffers() because they are using full memory barrier
using atomics on x86, and since i am using AllocMem() on the right
places, this means that i am safe also because heap memory allocated
with AllocMem() is never stored in registers on the Delphi and
FreePascal compilers.
 
 
So don't worry, i am coming soon with an updated version
of my C++ synchronization objects library that will be
great.
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 10 04:08PM -0700

Hello....
 
I think that we have to be more precise...
 
I think a variable to be visible needs a full memory barrier,
this is why the windows function FlushProcessWriteBuffers() is needed
in the writer side of my scalable Asymmetric reader-writer mutex
algorithms. That's the same for the Asymmetric rw_mutex of Dmitry Vyukov.
 
This bug doesn't show in my other algorithms, it just show in
my scalable Asymmetric reader-writer mutex algorithms.
 
So don't panic, i will try to correct this bug.
 
 
Thank you,
Amine Moulay Ramdane,
Ramine <ramine@1.1>: May 10 03:17PM -0700

Hello....
 
 
My C++ synchronization objects library was updated..
 
I have just updated my C++ synchronization objects library,
i have made some variables "volatile" in my scalable Asymmetric
Distributed Read-Writer Mutex algorithms, to be sure of visibility
accross cores, so now you can be more confident.
 
So you can download my new and extended C++ synchronization objects
library from:
 
https://sites.google.com/site/aminer68/c-synchronization-objects-library
 
 
 
Thank you,
Amine Moulay Ramdane.
Ramine <ramine@1.1>: May 10 03:37PM -0700

Hello,
 
Please take a look at the source code of the Delphi XE
DRWLock here:
 
https://sites.google.com/site/aminer68/scalable-distributed-reader-writer-mutex
 
I have delclared the following variables in LW_RWLockx.pas
"volatile" like this:
 
[Volatile] FCount1: PMyRecord1;
[Volatile] FCount2: PMyRecord2;
[Volatile] FCount3: PMyRecord3;
[Volatile] nbr: PMyRecord4;
 
And i have delclared the following variable in RWLockx.pas
"volatile" like this:
 
[Volatile] FCount1: PMyRecord1;
[Volatile] FCount2: PMyRecord2;
[Volatile] FCount3: PMyRecord3;
[Volatile] nbr: PMyRecord4;
[Volatile] nbr1: PMyRecord5;
 
 
So now you can be more confident of visibility accross cores.
 
 
Thank you,
Amine Moulay Ramdane.
You received this digest because you're subscribed to updates for this group. You can change your settings on the group membership page.
To unsubscribe from this group and stop receiving emails from it send an email to comp.programming.threads+unsubscribe@googlegroups.com.
Posted by at

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)