Silly Threads

After working with Go for a while, it seems quite silly that other High Level Languages expect us to work directly with the low level details of Hardware Threads.

In languages such as Ruby or Java, I want to code at a “High Level”. I want to write what I mean, not exactly how it should be implemented by the underlying system. I expect the system to handle what values should go into what registers and the details of memory management.

Instead, I want to expression, intuitively, what kind of thought process should run as a separate thread of execution in the program. What part of the application should use parallelism. And, in the end, have the compiler and runtime system worry about the details of what actual hardware thread that generated code will run on, and how to use that thread to the best of its ability. If that means scheduling multiple of these thought processes on the same hardware thread, or even moving a process between hardware threads, then so be it.

So its a surprised, when I’m asked, in a HL Language, to defined the exact code for a hardware thread. And then to be expected to use that thread in the most optimized fashion. To have the job of ensuring every moment that thread is fully utilized, even while my code might be waiting on I/O or polling. Instead, I would expect the compiler and the runtime to deal with that.

Go seems to use a combination of both Green Threads and Red (hardware) Threads to achieve this goal. Fully utilizing a hardware thread by (pseudo) pre-emptively swapping green threads across it.

This leaves it up to the programmer to simply define the conceptual threads of execution and where parallelism is “desired”, and puts the burden of fully utilizing the hardware on the language implementation, itself. As should be the case for HL Languages.

Event-based programming is a similar scenario. I have nothing against it myself, but I see programming purely in events, as another crutch where the programmer is forced to optimize on behalf of the language implementation, in order to fully utilize the hardware.

I’d like to see this form of combination of threading implementations or separate Language & Hardware Threading models included in some other, more popular languages. I feel this kind of abstraction goes hand in hand with High Level Programming.

Show your support

Clapping shows how much you appreciated Jason Stillwell’s story.