Hello,

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

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 it is not NP-hard, 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 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 of my philosophy about ThreadSanitizer and about Go programming language and more of my thoughts..

I think i am really smart, and here is the second weakness of Go
programming language, so Go programming language is using ThreadSanitizer algorithm in its race detector so that to detect race conditions, but here is the weakness of ThreadSanitizer:

So read carefully the following paper about ThreadSanitizer:

https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/35604.pdf

And it says in the conclusion the following:

"ThreadSanitizer uses a new algorithm; it has several modes of operation, ranging from the most conservative mode (which has few false positives but also misses real races) to a very aggressive one (which
has more false positives but detects the largest number of
real races)."

So as you are noticing since the very agressive mode of Threadsanitizer doesn't detect "all" the data races, so then it is a problem, so then CSP(Communicating sequential processes) model can not help Go, since read my below thoughts so that to understand, so then it is not "scalable", so it is not good, since you can still take a lot of time to verify a big project so that to find the remaining data races that are not detected by ThreadSanitizer..

More of my philosophy about the Go programming language and its big defect and more of my thoughts..

I think i am really smart, and i will make you understand the big defect of Go programming language, and it is that so that to avoid effectively
race conditions with the CSP(Communicating sequential processes) model,
you have to have different memory address spaces for different processes
that are distributed accross different machines or local to a machine, so if you use threads or lightweight thread like is using Go programming language, so then CSP(Communicating sequential processes) model will not work, since in the same memory adress space, you can still have race conditions. So notice carefully how superpascal is doing it by using parallel "processes" with different memory address spaces by reading the following:

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

Message passing of MPI for distributed programming is doing the same.

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: