I love to single thread but nobody else seems to. A typical situation would be making a sandwich for one kid while two others are trying to talk to me at the same time, each rising in volume to cut through the noise of the other. Partner explains in roundabout way that something is needed tomorrow. I wonder what to do with that information and wish it had been communicated in fewer words while making the sandwich. Then the phone rings.
then you tell the kid to hold on, i’m making a sandwich give me a minute and teach them to wait a minute, tell your partner to sit together for breakfast or lunch to go over complicated thing, and don’t answer the phone, let the machine get it if you’re doing something. if it’s important right here, right now, then they can call back or you can call back after you’re done doing the thing.
modern society teaches us to be available to everything all at the same time, when we really need to learn how to slow down and refocus our thoughts on one thing at a time.
Single Treading is easy and hard at the same time. I Program MCU with only one core and no real hardware support for preemtive multi tasking. i sometimes have to resort to interupts to get a somewhat Multitasking but on the other hand my code runs as i have wrote it. It makes you think more about the problem. i see may programs nowerdays just throwing Threads, co-routines and memory on problems till the speed is acceptable. sorry my english no native speaker, and if i use AI to make the wording better i get complains using AI....
I've read that the (first?) preemptive multi-tasking was implemented in Apollo lander, to leave more processing power to more critical sensors. No one though of it in such general terms though.
This metaphor totally gets muddied once you consider some of the most optimized programs are run on a single thread in an event loop. Communication between threads is expensive, epolling many io streams is less so. Not quite sure what implications this has in life but you could probably ascribe some wisdom to it.
I have a 16 core M4 Max and running at a fraction of the potential maximum speed just isn't very optimal on modern CPUs like that.
Threading is hard, especially if they share a lot of state. Memory management with multiple threads sharing stuff is hard and ideally minimized. What is optimal very much depends on the type of workload as well. Not all workloads are IO dependent, or require sharing a lot of state.
Using threads for blocking IO on server requests was popular 20 years ago in e.g. Java. But these days non blocking IO is preferred both for single and multi threaded systems. E.g. Elasticsearch uses threading and non blocking IO across CPU cores and cluster nodes to provide horizontal scalability for indexing. It tends to stick to just one indexing thread per CPU core of course. But it has additional thread pools and generally more threads than CPU cores in total.
A lot of workloads where the CPU is the bottleneck that have some IO benefit from threading by letting other threads progress while one is waiting for IO. And if the amount of context switching can be limited, that can be OK. For loads that are embarrassingly parallel with little or no IO and very limited context sharing, a 1 thread per CPU core tends to be the most optimal. It's really when you start having more than threads than cores that context switching becomes a factor. What's optimal there is very much dependent on how much shared state there is and whether you are IO or CPU limited.
In general, concurrency and parallelism tend to be harder in languages that predate when threading and multi core CPUs were common and lack good primitives for this. Python only recently started addressing the GIL obstacle and a big motivation for creating Rust was just how hard doing this stuff is in C/C++ without creating a lot of dead locks, crash bugs, and security issues. It's not impossible with the right frameworks, a lot of skill and discipline of course. But Rust is getting a well deserved reputation for being very optimal and safe for this kind of thing. Likewise functional languages like Elixir are more naturally suited for running on systems with lots of CPUs and threads.
Single-threading is also what allows you to stay up all night writing the 8 page essay that's due at 6:00am, what lets you drive for hours on end, what remembers protocol during a crisis. Not detracting from the OP's point at all, just single threading doesn't always have to be pleasant. One of its advantages is powering you through unpleasantries and getting what needs to be done done. Sometimes when we think we are 'multitasking,' we're just looking for ways to avoid the problem.
Every one of your examples are things that I find really enjoyable. As someone who is a terribly scatter brained procrastinator, the 6AM deadline is clarifying. Realizing at 11:30pm that I haven't started the essay is (or was, long ago) a jolt of wakefulness and focus. The time between 11:45pm and 5:45am flies by in a blur. Driving 1000mi in a day--18+hr of focus. Keep the speed high enough above the speed limit to make decent time over ground but avoid the risk of a sneaky traffic cop. Take advantage of the lulls in traffic, long sight lines (or tight, windy sections) to increase your average speed. Eat just enough to not lose energy but not enough to not be hungry--a little hunger sharpens focus. Drink enough water to not be totally dehydrated, but little enough that your bathroom breaks coincide with fuel stops. Pager goes off at 3AM. Critical alert, connection pools full, database CPU 100%, p99 response times equal to the configured timeout, circuit breakers tripping. The urgency gives life some meaning. You were groggy and sleepy 1min ago and now you're blasted wide awake, throttle firewalled. Don't threaten me with a good time ;)
I love reading this article start to finish. I really love the way the author has explained. And believe this is a tech-savvy explanation of mindfulness.
1. https://www.apa.org/topics/research/multitasking - Not a study. Focuses on productivity (not health, or perceived well-being, supports the idea that the brain have dedicated structures for multi-tasking.
I am aware that there are cognitive loads on some kinds of multi-tasking. That does not translate to all kinds of multi-tasking though.
To say that "the brain is like a computer, single thread" is misleading. There are scenarios in which the brain exceeds in multi-tasking (playing instruments like drums, playing games, etc), and there is plenty of evidence that we're tuned for it in all kinds of ways (but not all of them).
Furthermore, I'm not defending we should multi-task. I just think the metaphor and the "brain is mono thread" idea is both wrong and dumb.
A lot of the time work has this character also.
reply