Let's see what the future brings and also how well arduino will be accepted by "professionals" who know how to program. Besides, as you say, once you understand the concepts of multi-threading it's much easier than poking around in ISR and re-inventing semaphores, mutexes and message queues...
Somewhat surprised about the resistance against threads
, before I started programming on arduino I don't think I have made a program that don't use multiple threads in several years.. Extremely practical and puts things where they need to be.. The alternative is implementing it yourself if you need to do more than one thing, calling functions from loop and testing in the functions if they need to run..
Would be better having having a preemptive os with shiftOut and spi etc. able to do what they need. I assume there are significant delays a lot of places that could be utilized by other threads .
I'm not against threads; I just strongly advise the typical Arduino user against their use in order to avoid problems that will surely follow. I've done lots of synchronization bug fixing in commercial and open source code, even in country-wide telecommunication systems currently running on the top first-world countries. When I say threading is hard, it is. It's hard to do it right (note that the real issue is thread synchronization, not the threads per se); not the trivial stuff like a pair of threads each blinking its own LED, of course, but who needs a do-nothing-useful program. I myself choose to use a preemptive model if the threading one isn't really needed. Or, if have a thing or too that really need accurate timing, just use a timer interrupt to do that little thing (as less as possible) and have a non-threaded main program.Many threaded programs out there are like a semiconductor used a bit out of spec - one day, maybe, it will bite you.