5 ms·
I gotta say, as a programmer "of a certain age", a lot of recent advances have an everything-old-is-new-again feel to me. When I first heard of "threads" in t
by jp57 4y ago
I gotta say, as a programmer "of a certain age", a lot of recent advances have an everything-old-is-new-again feel to me. When I first heard of "threads" in the 90s, the term specifically referred to a mechanism for intra-process concurrency that was "lightweight", i.e. it didn't have the heavy overhead of forking a new OS process. IIRC they weren't even preemptively multitasked. Then preemptive "OS threads" became the new hotness and everything using cooperative threads was old and busted. Now a generation has passed and we have "virtual threads" or things like asyncio to solve the problems created by the thing that solved the problems of the thing before.
A similar thing has happened at the OS level with support for multiple programs. Computers started out running one program at a time. Then "multitasking" was invented, and along with it all kinds of things to make it safer and easier like users and permissions and protected memory, and it was great, many different users could run different programs on the same machine. Then we moved from running statically linked binary executables to dynamic linking and interpreted languages that load libraries at run time. Managing environments for different programs on one machine got hard. VMs and hypervisors let us segment a machine into virtual machines where the environments were easy to control. But VMs were a heavyweight solution for managing environments, so along came containers, which are kind of virtual virtual machines.
So now we're in the position where it's perfectly normal to run a program with several virtual threads running in a "real" thread in a Java virtual machine running inside a Docker container running on a VM instance in a hypervisor on some giant box somewhere. And if we're all living in a simulation, then its' probably turtles all the way down.
I don't mean this entirely as a "get off my lawn" rant. I recently re-implemented an io-heavy threaded program using asyncio and I found it genuinely better. It was easier to reason about what was happening and to get our task dependencies to execute in the right order. The code is simpler and I'm pretty happy about it. But I fully expect asyncio and virtual threads to go out of fashion in ten years, and some new preemptive, OS-managed thing will come along and become the new hotness.
ps - I found this quote in the description of Virtual Threads[1]
> Virtual threads are preemptive, not cooperative — they do not have an explicit await operation at scheduling (task-switching) points. Rather, they are preempted when they block on I/O or synchronization.
Sorry, that's not preemption, that's yielding at specific safe points. I.e. cooperative multitasking. For example, Classic MacOS's cooperative multitask didn't have an explicit yield, it yielded automatically when you polled for a new event.
[1] - http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.html#right-sizing-threads http://cr.openjdk.java.net/~rpressler/loom/loom/sol1_part1.h...