Read again, i correct

[Ramine]

Hello................

Here is how to implement pure functions of Haskel and Lisp in C++..

First you have to call a constructor that will put the global variables
as pointers for example in there respective queues..

And after that each method that wants to access a global variable will
take the global variable from the queue and copy it in a local
variable and work with it locally, and after that it will put
it back in its global queue , it's like message passing and
it's like pure functions with Mvars in Haskel and this mechanism is good
and will avoid race conditions in Object oriented programming.


For Deadlocks use this:

Use Lock Hierarchies to Avoid Deadlock

http://www.drdobbs.com/parallel/use-lock-hierarchies-to-avoid-deadlock/204801163


Thank you,
Amine Moulay Ramdane.

[Ramine]

Hello...........

Fist solution:

I think that C++ and ADA and Object Pascal must make the data types
objects, and make datastructures objects and make IO objects etc. and
wrap those objects with a scalable reader-writer lock or transactional
memory, and the compiler designers and implementors must test those
objects correctly to ensure that they work correctly, this will ensure a
level of security that avoids race conditions that is tolerable,
so no need for pure functions and Mvars of Haskel and Lisp.

Or you can use this solution:

About C++ and my following enhancement to it...

C++ must add properties that you can access only from the constructor
and can not be accessed from the methods of the object.

This way you will be able to implement more cleanly my following
implementation:

First you have to call a constructor that will put the global variables
as pointers for example in there respective queues..

And after that each method that wants to access a global variable will
take the global variable from the queue and copy it in a local
variable and work with it locally, and after that it will put

it back in its global queue , and other threads will block waiting
for the variables on there respective queues, it's like message passing

and it's like pure functions with Mvars in Haskel and this mechanism is
good and will avoid race conditions in Object oriented programming.

If you say to me that pure functions of Lisp and Haskel are pure
functions , but with my previous implementation you still can
by error forget to put your global variables that is
shared by threads in the properties that can not be accessed
by the object or in there respective global queues, i will say that
my implementation easy the job for us, because defining what is shared
and putting it in the properties that can not be accessed from the
object is easy and is as easy as making an error on sequential
programming, so in my opinion this level of security can be tolerated in
Object oriented programming without using Functional programming, other
than that we also have Transactional memory that is composable and easy
to use to solve our parallel programming problems in Object oriented

[Ramine]

Hello....

About USL methodology here:

http://www.perfdynamics.com/Manifesto/USLscalability.html

I have understood the USL methodology..

USL methodology doesn't predict scalability because scalability
is dependant on the nature of data also.

But when you fix the data and test with USL methodology , you
can quantify the level of Contention (with strength α)
due to waiting or queueing for shared resources and the level of
Coherency (with strength β) due to the delay for data to become
consistent (or coherent) by virtue of point-to-point exchange,
and by forecasting on a fixed data you can have a better idea
of how your parallel system scales, so it is a powerful tool

Also i have easy the job for you by compiling my Universal Scalability
Law for Delphi and FreePascal programs to windows 32bit and 64bit
executables, they are really fantastic and powerful, they are GUI and
command line, please read about them and download them from here:

https://sites.google.com/site/aminer68/universal-scalability-law-for-delphi-and-freepascal