| Lynn McGuire <lynnmcguire5@gmail.com>: Sep 26 05:37PM -0500 "CppCon 2019: Herb Sutter "De-fragmenting C++: Making Exceptions and RTTI More Affordable and Usable"" https://www.youtube.com/watch?v=ARYP83yNAWk&t=1s That is a 1.5 hour speech ! Lynn |
| James Kuyper <jameskuyper@alumni.caltech.edu>: Sep 26 06:24PM -0400 On 9/26/19 5:28 PM, Richard wrote: >> How portable is it to non-POSIX systems? > In particular, C and C++ don't assume POSIX, even though they > originated from POSIX-like environments. The C standard only mentions POSIX once, in the Bibliography section. However, by my count, the C++ standard refers to POSIX 92 times. As far as I can tell (I didn't check closely), nothing it says about POSIX is mandatory, but in several places it encourages non-POSIX implementations to emulate POSIX behavior to the extent possible. |
| aminer68@gmail.com: Sep 26 02:54PM -0700 Hello, I think i have just found the solution for buffer overflow problem for memory safety, i will explain it now: As you have noticed i have implemented my Getmem_aligned() and Freemem_aligned() for Delphi and Freepascal, here it is: https://sites.google.com/site/scalable68/getmem_aligned-for-delphi-and-freepascal I think you can get the idea from the source code of it, as you have noticed i am doing this (it is in modern Delphi Object pascal for Delphi and Freepascal compilers): ================================================ procedure getmem_aligned(alignment:cardinal;var ptr:pointer;size:cardinal); var ptr1,ptr2,ptr3:pointer; begin ptr := AllocMem(size + (2*alignment) + sizeof(pointer)); ptr1:=pointer(int(ptr)+sizeof(pointer)); ptr2 := Pointer((int(ptr1) + Alignment - 1) and not (Alignment - 1)); ptr3:=pointer(int(ptr2)-sizeof(pointer)); intptr(ptr3)^:=int(ptr); ptr:=ptr2; end; procedure freemem_aligned(ptr:pointer); var ptr1,ptr2:pointer; begin ptr1:=pointer(int(ptr)-sizeof(pointer)); int(ptr2):=intptr(ptr1)^; freemem(ptr2); end; ======================================================== So as you have noticed i am adding a memory size of a "pointer", like this: AllocMem(size + (2*alignment) + sizeof(pointer)); So the idea for buffer overflow is to add one other pointer to the AllocMem() that you access like i am accessing the real pointer in my above Freemem_aligned(), like this: AllocMem(size + (2*alignment) + sizeof(pointer) + sizeof(pointer)); So you will have two fields , one for the size of the reserved memory and one for the address of the real pointer, after that you will code the CopyMemory() that works with Pointers and PWidechar and Pchar types of modern Object pascal for Delphi and Freepascal compilers, and i think this is easy to do for me and the new CopyMemory() will issue an exception if there is a buffer overflow and it will solve the problem of buffer overflow for Delphi and Freepascal, and you can use jclDebug or madExcept or EurekaLog for Delphi to print the line of the source code where the Buffer overflow exception happened, here is the free jclDebug that you can get from here: https://wiki.delphi-jedi.org/wiki/JCL_Help:JclDebug.pas So read my previous thoughts about "Fearless Security: Memory safety" to understand more my own thoughts: I have just read the following webpage about "Fearless Security: Memory safety": https://hacks.mozilla.org/2019/01/fearless-security-memory-safety/ Here is the memory safety problems: 1- Misusing Free (use-after-free, double free) I have solved this in Delphi and Freepascal by inventing a "Scalable" reference counting with efficient support for weak references. Read below about it. 2- Uninitialized variables This can be detected by the compilers of Delphi and Freepascal. 3- Dereferencing Null pointers I have solved this in Delphi and Freepascal by inventing a "Scalable" reference counting with efficient support for weak references. Read below about it. 4- Buffer overflow and underflow This has been solved in Delphi by using madExcept, read here about it: http://help.madshi.net/DebugMm.htm You can buy it from here: http://www.madshi.net/ And about race conditions and deadlocks problems and more, read my following thoughts to understand: I will reformulate more smartly what about race conditions detection in Rust, so read it carefully: You can think of the borrow checker of Rust as a validator for a locking system: immutable references are shared read locks and mutable references are exclusive write locks. Under this mental model, accessing data via two independent write locks is not a safe thing to do, and modifying data via a write lock while there are readers alive is not safe either. So as you are noticing that the "mutable" references in Rust follow the Read-Write Lock pattern, so this is not good, because it is not like more fine-grained parallelism that permits us to run the writes in "parallel" and gain more performance from parallelizing the writes. 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, 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? read my above thoughts about it. 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.37, 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 |
| 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.lang.c+++unsubscribe@googlegroups.com. |
No comments:
Post a Comment