On 04/30/2024 01:33 PM, Chris M. Thomasson wrote:
On 4/30/2024 1:22 PM, Lawrence D'Oliveiro wrote:
On Tue, 30 Apr 2024 11:25:13 +0200, Bonita Montero wrote:
>
Am 30.04.2024 um 11:09 schrieb Lawrence D'Oliveiro:
On Tue, 30 Apr 2024 09:37:18 +0200, Bonita Montero wrote:
>
Am 30.04.2024 um 08:42 schrieb Lawrence D'Oliveiro:
On Tue, 30 Apr 2024 07:59:06 +0200, Bonita Montero wrote:
>
Am 30.04.2024 um 06:09 schrieb Lawrence D'Oliveiro:
>
On Tue, 30 Apr 2024 05:58:31 +0200, Bonita Montero wrote:
>
Having a single thread and using state machines is more effortz.
>
It would indeed. That’s why coroutines (async/await) are so handy.
>
Using a thread is even more handy.
>
Do you know what a “heisenbug” is?
>
[No]
>
Do you know what a “race condition” is?
>
[No]
>
You haven’t actually done much thread programming, have you?
>
Apparently not! Yikes!
I think a lot of people had heard of the ACE threads toolkit
out of WUSTL. (It's a portability abstraction layer and
some mutexes.) Or, the "ACE object-oriented thread
encapsulation class library", for C++.
https://openscholarship.wustl.edu/cse_research/389/I'm reading this again and it makes a lot more sense
now than it did then, and it was totally profound.
https://www.enseignement.polytechnique.fr/profs/informatique/Leo.Liberti/public/computing/parallel/threads/comp.programming.threads-faq.htmlBack in the day there were some good books on "systems programming"
and "portable programming", like the Addison-Wesley series. When it
comes to Windows or NT, which is still sort of what Windows is,
there's Windows Internals, like 3'rd and 4'th edition, about
where these things in Windows are born. It's good when eating
for digesting to thoroughly know the food, to thoroughly chew
the food, and to know where the food comes from. "Advanced Windows".
"Addison-Wesley Professional."
I'm a fan of BM's style, it's thoroughly sort of evolved.
It's like "if there's a type_trait I'll use it, if not
I know the constants". Also "I have a pretty idea what
code the compiler generates for this code, and whether
it's extern linkage or not, and what it is if it is."
"What is its ordinals, what is its exports." Then knowing
about type_traits and this kind of thing, and metaprogramming
with templates in C++, is a pretty strong strength.
It's a good idea when eating the food to know where
the food comes from, and, you know, thoroughly chew
the food. Knowing where babies come from, this kind
of thing.
About design and "correctness, correctness, correctness:
pick one", there's something to be said for algorithms,
that resolve basically to compare-and-swap or CMPXCHG,
often about an idea of single-producer single-consumer
with a list of buffers and consuming the head of the
buffer and concatenating to the tail of the buffer,
while the consumer sees only the head and the producer
concatenates only to the tail.
Making modules so that modules are well-defined and
independent or, you know, with their logical and concrete
adapters, and then making it so that they're machines
and all sort of work together, is a challenge of
"library design". I.e., libraries and patterns are
supposed to be composed and consumed by users, programmers,
not necessarily written by them. Yet, it's the users'
fault if they don't know where their food comes from.
"Components", libraries, modules, ....
Composability is key. At some point somebody's going
to just concatenate the files and compile them.
These days things are often sort of simplified
into "the four facilities: DB MQ WS FS", with
the atomicity of transactions, consuming the queue,
operations and faults, and filesystem atomicity.
Threads across programming languages
Re: Threads across programming languages