Re: "Where is my C++ replacement?"
Am 18.06.2014 12:09, schrieb Melzzzzz:
Another necessary change when going your way is to split the bulky
large applications in small state engines that communicate only over
documented and verifiable interfaces. This is a SOA-like approach. I
have done this so far in the 90'. Surprisingly this was in no way
complex. The code of most of the functional units fit to one or two
screens. And race conditions are almost gone. But each unit was a
thread and most OS cannot reasonably deal with thousands of
(sleeping) threads. On this hardware a sleeping thread did not
consume any resources except for it's (small) stack memory.
Well, 'go' has green threads that do exactly what you describe.
You can have thousands(hundreds of thousand?) of those without problem.
C++ does not have scheduler built in ,like 'go' has,
and that is only difference as I see.
The concept does not really require a scheduler. The Idea is that a
sleeping thread need not to have any resources except for his state
variables, i.e. it's stack. This implies that no one needs to keep track
of sleeping threads. A sleeping thread only makes sense if there is
anyone who could wake him up. An that's the point. All you need for this
purpose is to place enough information at the synchronization point that
other threads can wake you up. This is basically your stack pointer,
nothing else. To activate you need to load this stack pointer in the CPU
and execute a return from function to load the code where to continue.
This is the point why you can never implement this concept in C++ - at
least not portable.
The synchronization points could be whatever you like, from a semaphores
wait queue over hardware interrupts or IPC communication channels.
Basically the CPU scheduling is nothing else than a semaphore too. If
you have more threads than CPU cores they have to wait for a core to
become ready. Of course, a thread could place it's wake up pointer at
several places (alternation).
Marcel