• More of my philosophy about programming languages about lock-based syst

    From World-News2100@21:1/5 to All on Wed Dec 1 17:28:56 2021
    Hello,



    More of my philosophy about programming languages about lock-based
    systems and more..

    I am a white arab from Morocco, and i think i am smart since i have also invented many scalable algorithms and algorithms..


    I think we have to be optimistic about lock-based systems, since race conditions detection can be done in polynomial-time, and you can notice
    it by reading the following paper:

    https://arxiv.org/pdf/1901.08857.pdf

    Or by reading the following paper:

    https://books.google.ca/books?id=f5BXl6nRgAkC&pg=PA421&lpg=PA421&dq=race+condition+detection+and+polynomial+complexity&source=bl&ots=IvxkORGkQ9&sig=ACfU3U2x0fDnNLHP1Cjk5bD_fdJkmjZQsQ&hl=en&sa=X&ved=2ahUKEwjKoNvg0MP0AhWioXIEHRQsDJc4ChDoAXoECAwQAw#v=
    onepage&q=race%20condition%20detection%20and%20polynomial%20complexity&f=false

    So i think we can continu to program in lock-based systems, and about composability of lock-based systems, read my below previous thoughts
    about it:

    More of my philosophy about composability and Haskell functional
    language and more..

    I have just read quickly the following article about composability,
    so i invite you to read it carefully:

    https://bartoszmilewski.com/2014/06/09/the-functional-revolution-in-c/

    I am not in accordance with the above article, and i think that the
    above scientist is programming in Haskell functional language and it is
    for him the way to composability, since he says that the way of
    functional programming like Haskell functional programming is the
    the way that allows composability in presence of concurrency, but for
    him lock-based systems don't allow it, but i don't agree with him, and
    i will give you the logical proof of it, and here it is, read what is
    saying an article from ACM that was written by both Bryan M. Cantrill
    and Jeff Bonwick from Sun Microsystems:

    You can read about Bryan M. Cantrill here:

    https://en.wikipedia.org/wiki/Bryan_Cantrill

    And you can read about Jeff Bonwick here:

    https://en.wikipedia.org/wiki/Jeff_Bonwick

    And here is what says the article about composability in the presence of concurrency of lock-based systems:

    "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

    More about Channels, Concurrency and lightweight tasks and more..

    I think i am smart and i am like a software architect, and i am
    an inventor of many software scalable algorithms and algorithms, so
    i will continu to explain more:

    From a software architecting point of view, i think that Go programming language from Google has made some big software architecting errors, for example you can take a look at the architecting of channels in Go
    programming language from the source code and you will notice that the
    mutex of the channels is spinning about 1 ms or 2 ms, and it is not
    good, since it is not so efficient, since it is by analogy like when you
    have to prevent too much cache-coherence traffic by using queue locks, i
    mean that the mutex of the channels in Go language is spinning for 1 ms
    or 2 ms and it is not good since it makes the thing slow, since thread switching is slow and it is also not like convoy resistant, and it is
    not the only disadvantage, i will talk about the other disadvantages of
    Go and more in my next book about parallel programming and concurrency
    that i will sell, so i think that Go and Rust languages are not so
    efficient, read all my following thoughts so
    that to understand more:

    I have just looked quickly at the following video of Concurrency and
    Channels and lightweight tasks, and i invite you to look
    at it:

    Andy Wingo - Channels, Concurrency, and Cores: A new Concurrent ML implementation

    https://www.youtube.com/watch?v=7IcI6sl5oBc

    I think i am smart and i think that the above solution
    in the above video has the same problem as Go language with channels and
    light goroutines from Google, since i have looked at Go and is using
    mutexes in its implementation of Channels that
    are not so efficient, so the problem is that it is by logical analogy
    like the problem of a "monopolization" that is not so business friendly,
    since we can think that the others can still invent queues or locks or
    mutexes that are much more efficient, so how can they sell it
    "advantageously" to people around the world if Google or other
    compagnies are monopolizing with there Go language and such. So i think
    that this types of Concurrency with lightweight tasks and with channels
    that is included directly inside a language has its disadvantage that it becomes a not business friendly.

    And i think that Go and Rust have another disadvantage and here it is:

    More of my philosophy about the too much purism philosophy of Rust and
    more..

    I think i am smart, and i think that Rust compiler and language is too
    much "purist", it looks like the too much purism of Haskell functional programming language, since i say that Rust and Go don't provide us with
    OOP inheritance, but it is too much restrictive, and it is the
    deficiency of Rust, since inheritance has advantages and disadvantages,
    so we have to balance well and provide also with inheritance so that to
    be efficient, so i think that C++ and C# are better than Rust in this
    regard, and here is the advantages and disadvantages of OOP inheritance:

    https://www.ianswer4u.com/2017/09/oops-inheritance-advantages.html

    As a software developer you have to become more efficient and
    productive. So you need to make sure the code you write is easily
    reusable and maintainable. And, among other things, this is what
    inheritance gives you - the ability to reuse without reinventing the
    wheel, as well as the ability to easily maintain your base object
    without having to perform maintenance on all similar objects.

    More of my philosophy about Superpascal and about CSP(Communicating
    sequential processes) and more..

    I think i am smart, and i am also programming in Object Pascal
    of Delphi and Freepascal, and i think i am also a smart "Wirthian"
    programmer of the Wirthian familly of ALGOL-like languages, since i have programmed in Pascal and i have also programmed in Superpascal(You can
    read about it here: https://en.wikipedia.org/wiki/SuperPascal), and
    i have programmed in Object Pascal of Delphi and Freepascal, and i know
    more about Superpascal, that was an interesting enhancement of the
    pascal language, that brought an enhancement in a form of a "Forall"
    statement that is like a Parallel For loop, and that brought an
    enhancement in a form of "Channels" that look like Go channels and that
    permit to code parallel programs, so the Superpascal channels allowed us
    to program like in CSP(Communicating sequential processes) that is a
    formal language for describing patterns of interaction in concurrent
    systems. And CSP(Communicating sequential processes) is a member of the
    family of mathematical theories of concurrency known as process
    algebras, or process calculi, based on message passing via channels, so Superpascal Channels allowed us to avoid parallel bugs such as race
    conditions, but i think that those channels can also be used in a more
    simple way like in the following article, so that they permit to avoid
    race conditions and that's also i think a much better enhancement, so
    read the following article so that to know about the more simple way of
    using Go channels or Superpascal channels so that to avoid race conditions:

    https://fodor.org/blog/go-avoiding-race-conditions/

    And so that you get an idea about Superpascal, you can look
    at its source code in Freepascal here in Gitub:

    https://github.com/octonion/superpascal

    So as you notice that Superpascal programming language, that was
    invented in year 1993, has preceded Go programming language by providing Channels etc. that permit to do parallel programming by avoiding race conditions and such parallel programming bugs.

    But you have to know that i am smart and i have also enhanced
    Object Pascal of Freepascal and Delphi by inventing the following
    Threadpool that scales well and that supports parallel for loop,
    you can read about it carefully here in my websites:

    https://sites.google.com/site/scalable68/an-efficient-threadpool-engine-with-priorities-that-scales-very-well

    And i have also enhanced Object Pascal of Freepascal and Delphi by
    inventing a Scalable reference counting with efficient support for weak references, you can take a look carefully about it here in my websites:

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

    So as you notice that i am also an inventor of many scalable algorithms
    and algorithms..

    More of my philosophy about stack memory allocations and about
    preemptive and non-preemptive timesharing..

    I think i am smart, and as you are noticing in my below thoughts that
    i am abstracting smartly so that to make you understand preemptive and non-preemptive timesharing , other than that i will also give you
    an interesting Stack memory allocation algorithm in Delphi and
    Freepascal so that to use it smartly with my below sophisticated
    Stackful coroutines Library, so i will extend my sophisticated Stackful coroutines Library so that to support it smartly, and here it is:

    --

    var pool: array [1..limit] of integer;
    memory: array [min..max] of integer;
    top: integer;


    procedure initialize;

    var index: integer;

    begin
    for index := 1 to limit do
    pool[index] := empty;
    top := min − 1
    end;

    procedure allocate( index, length: integer; var address: integer);

    begin

    address := pool[index];
    if address <> empty then
    pool[index] := memory[address]
    else
    begin
    address := top + 1;
    top := top + length;
    if not (top <= max)
    then raise Exception.Create('Stack overflow..')

    end
    end;

    procedure release( index, address: integer);
    begin
    memory[address] := pool[index];
    pool[index] := address
    end;

    --


    More of my philosophy about about the paper and about preemptive and non-preemptive timesharing and more..

    I have just forgotten to post about who has written the following
    paper about cooperative and preemptive tasking:

    https://users.ece.cmu.edu/~koopman/pubs/koopman90_HeavyweightTasking.pdf

    Here is the Professor Phil Koopman of Carnegie Mellon University from Department of Electrical and Computer Engineering who has written
    this paper:

    https://users.ece.cmu.edu/~koopman/personal.html

    And note that i am calling, in my thoughts below, cooperative and
    preemptive tasking: "preemptive and non-preemptive timesharing"

    More of my philosophy about Intel 8051 controller and about preemptive
    and non-preemptive timesharing and more..

    I have just quickly read the following interesting paper and it says
    that judicious use of cooperative tasking techniques can also often meet
    an embedded system's multitasking requirements, while giving better
    performance and a simpler software environment than a preemptive
    multitasker, so read it carefully here:

    https://users.ece.cmu.edu/~koopman/pubs/koopman90_HeavyweightTasking.pdf

    And notice that it also says in the above paper that so that to meet
    the requirements with cooperative multitasking you have to move the time-critical code to interrupt-service routines. And let us look
    for example at the Intel 8051 controller here:

    https://www.electronicwings.com/8051/introduction-to-8051-controller

    So as you notice that it has many hardware interrupts that you can
    use so that to make the cooperative tasking efficient, and i think it
    also comes with two clock timers interrupts that you can use to
    implement preemptive multitasking if you want, and you have also to know
    about interrupt latency when programming embedded systems with hardware controllers, and you have to know that the hardware interrupts have to
    get serviced fast enough and often enough, so you shouldn't disable
    interrupts for too long a period of time, and just to give you an idea
    , look for example at the nonbuffered communication UART (Universal Asynchronous Receiver Transmitter) operating at 38,400 bits per second
    will interrupt every 208 microseconds. This is 1/38,400*8 because they
    will interrupt for every byte (8 bits), and a processor or controller
    running at 25MHz executes most of its instructions in
    2 or 3 system-clock periods. That would be an average of 120 nanoseconds (1/25,000,000*3). In theory, this means you could execute as
    many as 1,730 instructions in the interrupt interval. So that was only
    in theory, now you have to do the reality check. You must take into consideration that there are more interrupts than just that
    communication channel. The timer interrupt will be firing off every so
    often. And the communication interrupt itself will have interrupts
    disabled for good period of time, and not only that, but there is also
    the tasks switch that can be expensive, so you have to think about
    it efficiently.

    So i invite you to read my below thoughts about preemptive and
    non-preemptive timesharing and more so that to understand much more efficiently:

    More of my philosophy about preemptive and non-preemptive timesharing
    and more..

    I have just took a smart look at Modula-2 language(Modula-2 is a
    structured, procedural programming language developed between 1977 and
    1985 by Niklaus Wirth at ETH Zurich, and he has also developed Pascal
    language, read about Niklaus Wirth here: https://en.wikipedia.org/wiki/Niklaus_Wirth), and i think Modula-2
    language was among the first languages that has provided preemptive and non-preemptive timesharing with coroutines, but the preemptive
    timesharing in Modula-2 uses Interrupt handling using IOTRANSFER, but it
    is best reserved for programs that will run without operating system
    support. Installing an interrupt handler on a multiuser system is not feasi­ble because doing so would affect other users. (For this reason, IOTRANSFER is not a mandatory feature of Modula-2.) Even on single-user systems, IOTRANSFER can be difficult to use because installing an
    interrupt handler causes the old interrupt handler (which most likely
    belongs to the operating system) to be lost. So this is why i think that
    the best way in modern operating systems is to use non-preemptive
    timesharing with coroutines, so this is why i am providing you with my sophisticated implementation of stackful coroutines, read about it in my thoughts below:

    More of my philosophy about timesharing that is a Solution to Computer Bottlenecks..

    I invite you to look at the following very interesting video about
    timesharing that is a Solution to Computer Bottlenecks:

    https://www.youtube.com/watch?v=Q07PhW5sCEk

    I think i am smart, and you have to understand one important thing
    and it is: What is the difference between a software architect and
    a software engineer?, i think there is an important difference and it
    is also like abstracted in the following question:

    "How it is made?"

    So i think that software engineering works at a higher level than
    a software architect, this is why you will notice that i am
    quickly implementing a sophisticated stackful coroutines
    Library and i am quickly implementing setjmp() and longjmp() with
    x64 assembler or code machine, read my below thoughts about them, but
    you have to know that my sophisticated stackful coroutines Library
    does a kind of timesharing as in the above video, but i think that there
    is two kinds of timesharing: the preemptive one, and the non-preemptive
    one, but the difference is that the preemptive one does interrupt with a
    timer the coroutines from an external scheduler in
    a form of function, but notice below that i am implementing the
    non-preemptive timesharing in my sophisticated coroutines Library, but
    you have to be smart and notice that my way of doing is like the
    software architect way, since i am implementing it from the lowest level
    with x64 assembler routines that are part of the non-preemptive
    scheduler, but not only that, but you have also to look at how i am also implementing a
    sophisticated and much more rich interface in my stackful coroutines
    Library, so it is like both software achitecting and software
    engineering, so here is all my below thoughts that shows how i am
    implementing it quickly, so read it carefully since you have also to
    know what's the problem with the stack frames when architecturing and
    using the setjmp() and longjmp() so that to implement coroutines:

    More of my philosophy and precision about the link of the article and more..

    And notice that the link below of the article that shows the problem
    of implementing coroutines with just setjmp() and longjmp()
    is from the last semester of the second year of the course
    called "CS4411 Operating Systems" from Michigan Technological
    University, but i think i am smart and those courses are easy
    for me, so i invite you to read about this course that requires
    both the course of "CS3331 Concurrent Computing" and "CS3421 Computer Organization", and here it is:

    http://www.csl.mtu.edu/cs4411.ck/www/Home.html

    More of my philosophy about coroutines and about setjmp() and longjmp()..

    I think i am smart, and i will say that with setjmp() and longjmp()
    you can implement a generator or the like, but you can not implement
    coroutines with just setjmp() and longjmp(), and so that to understand
    it, i invite you to read the following article that shows how when you
    yield from a first function with a longjmp() to the main body of a
    program and when you call another functions with longjmp(), it can make
    the stack frames not work correctly, and when you understand it you will
    not use setjmp() and longjmp() alone so that to implement coroutines, so
    read the following article so that to understand the problem with
    the stack frames, and i am understanding it easily:

    https://www.csl.mtu.edu/cs4411.ck/www/NOTES/non-local-goto/coroutine.html

    So this is why i have also implemented my sophisticated stackful
    coroutines library so that to solve this problem, and here is my
    sophisticated coroutines library and read about it and download it from
    here:

    https://sites.google.com/site/scalable68/object-oriented-stackful-coroutines-library-for-delphi-and-freepascal

    More of my philosophy about setjmp() and longjmp() and generators and coroutines..

    I have just quickly implemented setjmp() and longjmp() in x64 assembler,
    and after that i have just implemented quickly a good example of a
    generator with my setjmp() and longjmp(), look at it below, and in
    computer science, a generator is a routine that can be used to control
    the iteration behaviour of a loop. All generators are also iterators. A generator is very similar to a function that returns an array, in that a generator has parameters, can be called, and generates a sequence of
    values. However, instead of building an array containing all the values
    and returning them all at once, a generator yields the values one at a
    time, which requires less memory and allows the caller to get started processing the first few values immediately. In short, a generator looks
    like a function but behaves like an iterator. So here is my
    implementations in freepascal and delphi and they are working perfectly:

    Here is my first unit that implements longjmp() and setjmp() and notice
    how i am saving the non-volatile registers and how i am coding it in
    x64 assembler:

    ======


    { Volatile registers: The calling program assumes registers
    RAX, RCX, RDX, and R8 through R11 are volatile.
    The contents of registers RBX, RSI, RDI, RBP, RSP, and
    R12 through R15 are considered non-volatile. Functions return
    values in RAX. }



    unit JmpLib64;

    {$IFDEF FPC}
    {$ASMMODE intel}
    {$ENDIF}
    interface

    type
    jmp_buf = record
    RBX,
    RSI,
    RDI,
    RSP,
    RBP,
    RIP,
    R12,
    R13,
    R14,
    R15: UInt64;
    end;

    { setjmp captures the complete task state which can later be used to
    perform a non-local goto using longjmp. setjmp returns 0 when it is
    initially called, and a non-zero value when it is returning from a call
    to longjmp. setjmp must be called before longjmp. }

    function setjmp(out jmpb: jmp_buf): UInt64;

    { longjmp restores the task state captured by setjmp (and passed in
    jmpb). It then returns in such a way that setjmp appears to have
    returned with the value retval. setjmp must be called before longjmp. }

    procedure longjmp(const jmpb: jmp_buf; retval: UInt64);
    implementation

    function setjmp(out jmpb: jmp_buf): UInt64; assembler;{$IFDEF FPC} nostackframe; {$ENDIF}register;
    asm
    { -> RCX jmpb }
    { <- RAX Result }
    MOV RDX, [RSP] // Fetch return address (RIP)
    // Save task state
    MOV [RCX+jmp_buf.&RBX], RBX
    MOV [RCX+jmp_buf.&RSI], RSI
    MOV [RCX+jmp_buf.&RDI], RDI
    MOV [RCX+jmp_buf.&RSP], RSP
    MOV [RCX+jmp_buf.&RBP], RBP
    MOV [RCX+jmp_buf.&RIP], RDX
    MOV [RCX+jmp_buf.&R12], R12
    MOV [RCX+jmp_buf.&R13], R13
    MOV [RCX+jmp_buf.&R14], R14
    MOV [RCX+jmp_buf.&R15], R15


    SUB RAX, RAX
    @@1:
    end;

    procedure longjmp(const jmpb: jmp_buf; retval: UInt64);assembler;{$IFDEF
    FPC} nostackframe; {$ENDIF}register;
    asm
    { -> RCX jmpb }
    { RDX retval }
    { <- RAX Result }
    XCHG RDX, RCX
    MOV RAX,RCX
    MOV RCX, [RDX+jmp_buf.&RIP]
    // Restore task state
    MOV RBX, [RDX+jmp_buf.&RBX]
    MOV RSI, [RDX+jmp_buf.&RSI]
    MOV RDI, [RDX+jmp_buf.&RDI]
    MOV RSP, [RDX+jmp_buf.&RSP]
    MOV RBP, [RDX+jmp_buf.&RBP]
    MOV R12, [RDX+jmp_buf.&R12]
    MOV R13, [RDX+jmp_buf.&R13]
    MOV R14, [RDX+jmp_buf.&R14]
    MOV R15, [RDX+jmp_buf.&R15]
    MOV [RSP], RCX // Restore return address (RIP)

    TEST RAX, RAX // Ensure retval is <> 0
    JNZ @@1
    MOV RAX, 1
    @@1:
    end;

    end.

    ================

    And here is my example of a generator with my longjmp() and setjmp():


    { In computer science, a generator is a routine that can be used to
    control the iteration behaviour of a loop. All generators are also
    iterators. A generator is very similar to a function that returns an
    array, in that a generator has parameters, can be called, and generates
    a sequence of values. However, instead of building an array containing
    all the values and returning them all at once, a generator yields the
    values one at a time, which requires less memory and allows the caller
    to get started processing the first few values immediately. In short, a generator looks like a function but behaves like an iterator. }

    program test_generator;

    {$APPTYPE CONSOLE}

    uses
    JmpLib64;

    type PtrInt = ^Integer;

    var
    childtask,maintask: jmp_buf;
    myarr1: array of integer;
    i,a:integer;
    Ptr1:PtrInt;

    function generator(var myarr:array of integer):integer;

    var i1:integer;
    val:integer;
    ptr:PtrInt;
    begin


    i1:=0;

    val:= setjmp(childtask);

    i1:=val-1;

    if val=0 then
    begin
    new(ptr);
    ptr^:=myarr1[i1];
    longjmp(maintask,uint64(ptr));
    end;

    if val=10
    then
    begin
    writeln('Exiting child..');
    exit;
    end;

    inc(i1);
    new(ptr);
    ptr^:=myarr1[i1];
    longjmp(maintask,uint64(ptr));
    end;

    begin

    setlength(myarr1,10);

    for i:=0 to 9
    do myarr1[i]:=i;

    uint64(ptr1):=setjmp(maintask);

    if ptr1=nil then generator(myarr1);

    a:=ptr1^;
    dispose(ptr1);

    if (a<=length(myarr1))
    then
    begin
    if a=length(myarr1)
    then longjmp(childtask,a+1)
    else
    begin
    writeln('Value returned by generator is: ',a);
    longjmp(childtask,a+1);
    end;
    end;

    setlength(myarr1,0);

    end.

    ====


    Thank you,
    Amine Moulay Ramdane.

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)