Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.programming.threads > #5072

Read again, i correct a typo because i write fast...

Show all headers | View raw

Hello..


Read again, i correct a typo because i write fast...

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, 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.

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.35 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.35 from:

https://sites.google.com/site/scalable68/scalable-reference-counting-with-efficient-support-for-weak-references


Thank you,
Amine Moulay Ramdane.

Back to comp.programming.threads | Previous | Next | Find similar | Unroll thread

Thread

Read again, i correct a typo because i write fast... Horizon68 <horizon@horizon.com> - 2019-06-30 13:24 -0700

csiph-web