Monday, September 16, 2019

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

aminer68@gmail.com: Sep 15 08:37AM -0700

Hello..
 
 
My new PERT++ and JNI Wrapper are here..
 
I am also posting this time about JNI Wrapper for Delphi and FreePascal that i have enhanced much more, and i think it is stable and complete, as you will notice that now JNI Wrapper automatically configure itself to support new versions of Oracle Java.
 
Please download the new JNI Wrapper from:
 
https://sites.google.com/site/scalable68/jni-wrapper-for-delphi-and-freepascal
 
 
And now here is my new PERT++:
 
 
PERT++ (An enhanced edition of the program or project evaluation and review technique that includes Statistical PERT) in Delphi and FreePascal
 
Version: 1.37
 
Authors: Amine Moulay Ramdane that has implemented PERT, Robert Sedgewick, Kevin Wayne.
 
Email: aminer68@gmail.com
 
Description:
 
This program (or project) evaluation and review technique includes Statistical PERT, it is a statistical tool, used in project management, which was designed to analyze and represent the tasks involved in completing a given project.
 
PERT++ permits also to calculate:
 
- The longest path of planned activities to the end of the project
 
- The earliest and latest that each activity can start and finish without making the project longer
 
- Determines "critical" activities (on the longest path)
 
- Prioritize activities for the effective management and to
shorten the planned critical path of a project by:
 
- Pruning critical path activities
 
- "Fast tracking" (performing more activities in parallel)
 
- "Crashing the critical path" (shortening the durations of critical path activities by adding resources)
 
- And it permits to give Risk for each output PERT formula
 
PERT is a method of analyzing the tasks involved in completing a given project, especially the time needed to complete each task, and to identify the minimum time needed to complete the total project. It incorporates uncertainty by making it possible to schedule a project while not knowing precisely the details and durations of all the activities. It is more of an event-oriented technique rather than start- and completion-oriented, and is used more in projects where time is the major factor rather than cost. It is applied to very large-scale, one-time, complex, non-routine infrastructure and Research and Development projects.
 
PERT and CPM are complementary tools, because CPM employs one time estimate and one cost estimate for each activity; PERT may utilize three time estimates (optimistic, most likely, and pessimistic) and no costs for each activity. Although these are distinct differences, the term PERT is applied increasingly to all critical path scheduling. This PERT library uses a CPM algorithm that uses Topological sorting to render CPM a linear-time algorithm for finding the critical path of the project, so it's fast.
 
You have to have a java compiler, and you have first to compile the java libraries with the batch file compile.bat, and after that compile the Delphi and Freepascal test1.pas program.
 
Here is the procedure to call for PERT:
 
procedure solvePERT(filename:string;var info:TCPMInfo;var finishTime:system.double;var criticalPathStdDeviation:system.double);
 
The arguments are:
 
The filename: is the file to pass, it's is organized as:
 
The first line is the number of jobs, the rest of each of the lines are: three time estimates that takes the job (optimistic, expected, and pessimistic) and after that the number of precedence constraints and after that the precedence constraints that specify that the job have to be completed before certain other jobs are begun.
 
info: is the returned information, you can get the job number and the start and finish time of the job in info[i].job and info[i].start and info[i].finish, please look at the test.pas example to understand.
 
finishTime: is the finish time.
 
criticalPathStdDeviation: is the critical path standard deviation.
 
I have also provided you with three other functions, here they are:
 
function NormalDistA (const Mean, StdDev, AVal, BVal: Extended): Single;
 
function NormalDistP (const Mean, StdDev, AVal: Extended): Single;
 
function InvNormalDist(const Mean, StdDev, PVal: Extended; const Less: Boolean): Extended;
 
For NormalDistA() or NormalDistP(), you pass the best estimate of completion time to Mean, and you pass the critical path standard deviation to StdDev, and you will get the probability of the value Aval or the probability between the values of Aval and Bval.
 
For InvNormalDist(), you pass the best estimate of completion time to Mean, and you pass the critical path standard deviation to StdDev, and you will get the length of the critical path of the probability PVal, and when Less is TRUE, you will obtain a cumulative distribution.
 
I have also included a 32 bit and 64 bit windows executables called PERT32.exe and PERT64.exe (that take the file, with a the file format that i specified above, as an argument) inside the zip, it is a very powerful tool, you need to compile CPM.java with compile.bat before running them.
 
I have also included a 32 bit and 64 bit windows executables called CPM32.exe and CPM64.exe (that take the file, with a the file format that i specified in the Readme.CPM file, as an argument) inside the zip, they run the CPM solver that you use with Statistical PERT that i have included inside the zip file, you need to compile CPM.java with compile.bat before running them.
 
The very important things to know about PERT is this:
 
1- PERT works best in projects where previous experience can be relied on to accurately make predictions.
 
2- To not underestimate project completion time, especially if delays cause the critical path to shift around, you have to enhance with point number 1 above or/and management time and resources can be applied to make sure that optimistic and most likely and pessimistic time estimates of activities are accurate.
 
Also PERT++ zip file includes the powerful Statistical PERT, Statistical PERT is inside Statistical_PERT_Beta_1.0.xlsx microsoft excel workbook, you can use LibreOffice or Microsoft Office to execute it, after that pass the output data of Statistical PERT to CPM library, please read the Readme.CPM to learn how to use CPM library, and please read and learn about Statistical PERT on internet.
 
Please read about Statistical PERT here:
 
http://www.statisticalpert.com/What_is_Statistical_PERT.pdf
 
 
Have fun with it !
 
Language: FPC Pascal v2.2.0+ / Delphi 7+: http://www.freepascal.org/
 
Operating Systems: Windows,
 
Required FPC switches: -O3 -Sd
 
-Sd for delphi mode....
 
Required Delphi switches: -$H+ -DDelphi
 
For Delphi XE-XE7 and Delphi tokyo use the -DXE switch
 
You can download my PERT++ from:
 
https://sites.google.com/site/scalable68/pert-an-enhanced-edition-of-the-program-or-project-evaluation-and-review-technique-that-includes-statistical-pert-in-delphi-and-freepascal
 
 
Thank you,
Amine Moulay Ramdane.
aminer68@gmail.com: Sep 15 08:04AM -0700

Hello,
 
 
Read more about Rust and Delphi and my inventions..
 
I think the spirit of Rust is like the spirit of ADA, they are especially designed for the very high standards of safety, like those of ADA, "but" i don't think we have to fear race conditions that Rust solve, because i think that race conditions are not so difficult to avoid when you are a decent knowledgeable programmer in parallel programming, so you have to understand what i mean, also you will notice by reading the following that in Rust by taking a mutable reference to a variable, you will notice that
you can not after that read or write to the variable, and
i think that this will lesser parallelism in scenarios that
you have more parallelism, so it is like the Read-Write Lock pattern,
so i think to higher parallelism in those scenarios you have to go
to unsafe Rust and this is not good.
 
Read more here to notice:
 
https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/
 
 
Now we have to talk about the rest of the safety guaranties of Rust, there remain the problem of Deadlocks, and i think that Rust is not solving this problem, but i have provided you with an enhanced DelphiConcurrent library for Delphi and Freepascal that detects deadlocks, and there is also the Memory Safety guaranties of Rust, here they are:
 
1- No Null Pointer Dereferences
2- No Dangling Pointers
3- No Buffer Overruns
 
But notice that I have solved the number 1 and number 2 by inventing my
scalable reference counting with efficient support for weak references
for Delphi and Freepascal, read below to notice it, and for number 3 read my following thoughts to understand:
 
More about research and software development..
 
I have just looked at the following new video:
 
Why is coding so hard...
 
https://www.youtube.com/watch?v=TAAXwrgd1U8
 
 
I am understanding this video, but i have to explain my work:
 
I am not like this techlead in the video above, because i am also an "inventor" that has invented many scalable algorithms and there implementions, i am also inventing effective abstractions, i give you an example:
 
Read the following of the senior research scientist that is called Dave Dice:
 
Preemption tolerant MCS locks
 
https://blogs.oracle.com/dave/preemption-tolerant-mcs-locks
 
As you are noticing he is trying to invent a new lock that is preemption tolerant, but his lock lacks some important characteristics, this is why i have just invented a new Fast Mutex that is adaptative and that is much much better and i think mine is the "best", and i think you will not find it anywhere, my new Fast Mutex has the following characteristics:

1- Starvation-free
2- Good fairness
3- It keeps efficiently and very low the cache coherence traffic
4- Very good fast path performance (it has the same performance as the
scalable MCS lock when there is contention.)
5- And it has a decent preemption tolerance.
 
 
this is how i am an "inventor", and i have also invented other scalable algorithms such as a scalable reference counting with efficient support for weak references, and i have invented a fully scalable Threadpool, and i have also invented a Fully scalable FIFO queue, and i have also invented other scalable algorithms and there inmplementations, and i think i will sell some of them to Microsoft or to
Google or Embarcadero or such software companies.
 
 
Read my following writing to know me more:
 
More about computing and parallel computing..
 
The important guaranties of Memory Safety in Rust are:
 
1- No Null Pointer Dereferences
2- No Dangling Pointers
3- No Buffer Overruns
 
I think i have solved Null Pointer Dereferences and also solved Dangling Pointers and also solved memory leaks for Delphi and Freepascal by inventing my "scalable" reference counting with efficient support for weak references and i have implemented it in Delphi and Freepascal (Read about it below), and reference counting in Rust and C++ is "not" scalable.
 
About the (3) above that is Buffer Overruns, read here about Delphi and Freepascal:
 
What's a buffer overflow and how to avoid it in Delphi?
 
http://delphi.cjcsoft.net/viewthread.php?tid=49495
 
 
About Deadlock and Race conditions in Delphi and Freepascal:
 
I have ported DelphiConcurrent to Freepascal, and i have
also extended them with the support of my scalable RWLocks for Windows and Linux and with the support of my scalable lock called MLock for Windows and Linux and i have also added the support for a Mutex for Windows and Linux, please look inside the DelphiConcurrent.pas and FreepascalConcurrent.pas files inside the zip file to understand more.
 
You can download DelphiConcurrent and FreepascalConcurrent for Delphi and Freepascal from:
 
https://sites.google.com/site/scalable68/delphiconcurrent-and-freepascalconcurrent
 
DelphiConcurrent and FreepascalConcurrent by Moualek Adlene is a new way to build Delphi applications which involve parallel executed code based on threads like application servers. DelphiConcurrent provides to the programmers the internal mechanisms to write safer multi-thread code while taking a special care of performance and genericity.
 
In concurrent applications a DEADLOCK may occurs when two threads or more try to lock two consecutive shared resources or more but in a different order. With DelphiConcurrent and FreepascalConcurrent, a DEADLOCK is detected and automatically skipped - before he occurs - and the programmer has an explicit exception describing the multi-thread problem instead of a blocking DEADLOCK which freeze the application with no output log (and perhaps also the linked clients sessions if we talk about an application server).
 
Amine Moulay Ramdane has extended them with the support of his scalable RWLocks for Windows and Linux and with the support of his scalable lock called MLock for Windows and Linux and he has also added the support for a Mutex for Windows and Linux, please look inside the DelphiConcurrent.pas and FreepascalConcurrent.pas files to
understand more.
 
And please read the html file inside to learn more how to use it.
 
 
About race conditions now:
 
My scalable Adder is here..
 
As you have noticed i have just posted previously my modified versions of DelphiConcurrent and FreepascalConcurrent to deal with deadlocks in parallel programs.
 
But i have just read the following about how to avoid race conditions in Parallel programming in most cases..
 
Here it is:
 
https://vitaliburkov.wordpress.com/2011/10/28/parallel-programming-with-delphi-part-ii-resolving-race-conditions/
 
This is why i have invented my following powerful scalable Adder to help you do the same as the above, please take a look at its source code to understand more, here it is:
 
https://sites.google.com/site/scalable68/scalable-adder-for-delphi-and-freepascal
 
Other than that, about composability of lock-based systems now:
 
Design your systems to be composable. Among the more galling claims of the detractors of lock-based systems is the notion that they are somehow uncomposable:

"Locks and condition variables do not support modular programming," reads one typically brazen claim, "building large programs by gluing together smaller programs[:] locks make this impossible."9 The claim, of course, is incorrect. For evidence one need only point at the composition of lock-based systems such as databases and operating systems into larger systems that remain entirely unaware of lower-level locking.
 
There are two ways to make lock-based systems completely composable, and each has its own place. First (and most obviously), one can make locking entirely internal to the subsystem. For example, in concurrent operating systems, control never returns to user level with in-kernel locks held; the locks used to implement the system itself are entirely behind the system call interface that constitutes the interface to the system. More generally, this model can work whenever a crisp interface exists between software components: as long as control flow is never returned to the caller with locks held, the subsystem will remain composable.
 
Second (and perhaps counterintuitively), one can achieve concurrency and
composability by having no locks whatsoever. In this case, there must be
no global subsystem state—subsystem state must be captured in per-instance state, and it must be up to consumers of the subsystem to assure that they do not access their instance in parallel. By leaving locking up to the client of the subsystem, the subsystem itself can be used concurrently by different subsystems and in different contexts. A concrete example of this is the AVL tree implementation used extensively in the Solaris kernel. As with any balanced binary tree, the implementation is sufficiently complex to merit componentization, but by not having any global state, the implementation may be used concurrently by disjoint subsystems—the only constraint is that manipulation of a single AVL tree instance must be serialized.
 
Read more here:
 
https://queue.acm.org/detail.cfm?id=1454462
 
And about Message Passing Process Communication Model and Shared Memory Process Communication Model:
 
An advantage of shared memory model is that memory communication is faster as compared to the message passing model on the same machine.
 
Read the following to notice it:
 
Why did Windows NT move away from the microkernel?
 
"The main reason that Windows NT became a hybrid kernel is speed. A microkernel-based system puts only the bare minimum system components in the kernel and runs the rest of them as user mode processes, known as servers. A form of inter-process communication (IPC), usually message passing, is used for communication between servers and the kernel.
 
Microkernel-based systems are more stable than others; if a server crashes, it can be restarted without affecting the entire system, which couldn't be done if every system component was part of the kernel. However, because of the overhead incurred by IPC and context-switching, microkernels are slower than traditional kernels. Due to the performance costs of a microkernel, Microsoft decided to keep the structure of a microkernel, but run the system components in kernel space. Starting in Windows Vista, some drivers are also run in user mode."
 
 
More about message passing..
 
An advantage of shared memory model is that memory communication is faster as compared to the message passing model on the same machine.
 
Read the following to notice it:
 
"One problem that plagues microkernel implementations is relatively poor performance. The message-passing layer that connects
different operating system components introduces an extra layer of
machine instructions. The machine instruction overhead introduced
by the message-passing subsystem manifests itself as additional
execution time. In a monolithic system, if a kernel component needs
to talk to another component, it can make direct function calls
instead of going through a third party."
 
However, shared memory model may create problems such as synchronization and memory protection that need to be addressed.
 
Message passing's major flaw is the inversion of control–it is a moral equivalent of gotos in un-structured programming (it's about time somebody said that message passing is considered harmful).
 
Also some research shows that the total effort to write an MPI application is significantly higher than that required to write a shared-memory version of it.
 
And more about my scalable reference counting with efficient support for weak references:
 
My invention that is my scalable reference counting with efficient support for weak references version 1.37 is here..
 
Here i am again, i have just updated my scalable reference counting with
efficient support for weak references to version 1.35, I have just added a TAMInterfacedPersistent that is a scalable reference counted version,
and now i think i have just made it complete and powerful.
 
Because I have just read the following web page:
 
https://www.codeproject.com/Articles/1252175/Fixing-Delphis-Interface-Limitations
 
But i don't agree with the writting of the guy of the above web page, because i think you have to understand the "spirit" of Delphi, here is why:
 
A component is supposed to be owned and destroyed by something else, "typically" a form (and "typically" means in english: in "most" cases, and this is the most important thing to understand). In that scenario, reference count is not used.
 
If you pass a component as an interface reference, it would be very unfortunate if it was destroyed when the method returns.
 
Therefore, reference counting in TComponent has been removed.
 
Also because i have just added TAMInterfacedPersistent to my invention.
 
To use scalable reference counting with Delphi and FreePascal, just replace TInterfacedObject with my TAMInterfacedObject that is the scalable reference counted version, and just replace TInterfacedPersistent with my TAMInterfacedPersistent that is the scalable reference counted version, and you will find both my TAMInterfacedObject and my TAMInterfacedPersistent
inside the AMInterfacedObject.pas file, and to know how to use weak references please take a look at the demo that i have included called example.dpr and look inside my zip file at the tutorial about weak references, and to know how to use delegation take a look at the demo that i have included called test_delegation.pas, and take a look inside my zip file at the tutorial about delegation that learns you how to use delegation.
 
I think my Scalable reference counting with efficient support for
weak references is stable and fast, and it works on both Windows and Linux, and my scalable reference counting scales on multicore and NUMA systems, and you will not find it in C++ or Rust, and i don't think you will find it anywhere, and you have to know that this invention of mine solves the problem of dangling pointers and it solves the problem of memory leaks and my scalable reference counting is "scalable".
 
And please read the readme file inside the zip file that i have just
extended to make you understand more.
 
You can download my new scalable reference counting with efficient support for weak references version 1.37 from:
 
https://sites.google.com/site/scalable68/scalable-reference-counting-with-efficient-support-for-weak-references
 
 
Thank you,
Amine Moulay Ramdane.
aminer68@gmail.com: Sep 15 07:22AM -0700

Hello,
 
 
Read more about Rust:
 
 
You will notice by reading the following that by taking
a mutable referenced to a variable, you will notice that
you can not after that read or write to the variable, and
i think that this will lesser parallelism in scenarios that
you have more parallelism, so it is like the Read-Write Lock pattern,
so i think to higher parallelism in those scenarios you have to go
to unsafe Rust and this is not good.

Read the following to notice it:
 
https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/
 
 
Also with Rust there is no deadlock detection.
 
 
Thank you,
Amine Moulay Ramdane.
aminer68@gmail.com: Sep 15 07:12AM -0700

Hello,
 
 
Yet about Rust..
 
 
You will notice by reading the following that by taking
a mutable referenced to a variable, you will notice that
you can not after that read or write to the variable, and
i think that this will lesser parallelism in scenarios that
you have more parallelism, so it is like the Reade-Write Lock pattern,
so i think to higher parallelism in those scenarios you have to go
to unsafe Rust and this is not good.

Read the following to noticed it:
 
https://manishearth.github.io/blog/2015/05/17/the-problem-with-shared-mutability/
 
 
 
Thank you,
Amine Moulay Ramdane.
aminer68@gmail.com: Sep 15 06:45AM -0700

Hello..
 
 
Today i will talk about Rust and about race conditions detection and deadlock detection..
 
I think Rust uses static detection , but the shortcoming of static detection is that there is there are also many false reports.
 
Other than that:
 
Safe Rust guarantees an absence of data races, which are defined as:
 
- two or more threads concurrently accessing a location of memory
- one of them is a write
- one of them is unsynchronized
 
A data race has Undefined Behavior, and is therefore impossible to perform in Safe Rust. Data races are mostly prevented through Rust's ownership system: it's impossible to alias a mutable reference, so it's impossible to perform a data race. Interior mutability makes this more complicated, which is largely why we have the Send and Sync traits (see below).
 
However Rust does not prevent general race conditions.
 
Read more here:
 
https://doc.rust-lang.org/nomicon/races.html
 
 
Also with Rust there is no deadlock detection.
 
 
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.

No comments: