Of course it's far better to start several threads, throw all the instructions at the task scheduler, have it execute them in a random order, deal with synchronization and concurrency issues. Of course that's better...
You have a program that needs to run tasks A,B,C (can be in parallel) followed by D (must be sequential, after the others).
You can optionally put everything in a serial process:
ABCD
Or you can design it like:
(A|B|C)D % where | indicates independence, parallelism
main() ->
Pids = lists:map(fun (F) -> spawn(F, [self()]) end, [fun a/1, fun b/1, fun c/1]),
lists:map(fun (Pid) -> receive
Pid -> ok
end
end, Pids),
d().
If you want to do that manually, without preemptive multitasking, have fun tuning it correctly. Do you have each parallel task look like this:
TaskA:
while(work-to-be-done)
do-work
yield
So now you have to tune each one of these if you really want the optimal results. And you have to know precisely what machine your target system is running. Yeah, in the embedded world, we've got that, and we pretty much do exactly what you suggest. Because we control the full stack. We know exactly what software runs on a CPU. We know exactly what the CPU speed will be. Memory access times. We can come up with near optimal, low-level coroutine style programs like this.
But most programs don't run in such a known, quantified, and understood environment.