Notes from kernel hacking in Hare, part 2: multi-threading | Hacker News Reader

Notes from kernel hacking in Hare, part 2: multi-threading

drewdevault.com

5 pointsddevault7 comments

> I have long promised that Hare would not have multi-threading, and it seems that I have broken that promise.

Arguably, another needed change in thinking should maybe be about supporting Windows and macOS, which together represent 90% of desktops and laptops.

There can be nothing wrong with changing one's mind. Particularly if it's for the better and earlier on in development. Few would find fault or blame, and perhaps many would agree.

The broken promise line is mostly a joke, I implemented threads for a specific use-case and I don't intend to generalize it. I definitely do not intend to support nonfree operating systems. It was not a mistake to skip them.

> our official stance is not actually as strict as “no threads, period”, though in practice for many people it might amount to that. There is nothing stopping you from linking to pthreads or calling clone(2) to spin up threads in a Hare program, but the standard library explicitly provides no multi-threading support, synchronization primitives, or re-entrancy guarantees

https://dl.acm.org/doi/10.1145/1065010.1065042

First of all, linking to pthreads and hoping for the best is a really dumb idea in Hare. However, the standard library could be forked (or a new one written) which provides good threads support, and Vulcan is one such standard library implementation, as discussed in the article.

With respect to this paper, it's interesting but mainly considers a C audience and makes many assumptions which do not apply to Hare. For instance, the kind of optimizations discussed in section 4.1 are prohibited by the Hare specification. So too for section 4.2, and much of the remainder of the paper deals with optimizations of this nature. Hare's approach is specifically to eschew many of these kinds of optimizations, such that the program you write is very similar to the program that runs, even at the cost of performance. The programmer is expected to optimize their program in many cases, rather than expecting the compiler to do it -- at a great potential cost to correctness and debuggability.

Anyway, this was an interesting read, thanks for sharing!

Do I have it right that a Hare compiler is supposed to emit barriers around every single memory access? Because it’s not just the compiler that can reorder writes, but the underlying CPU as well, which means the compiler has to be aware of concurrency during code generation if concurrency is to behave with any predictability. Which is the point of the article: concurrency cannot be provided as a pure library facility without any participation from the compiler. The language has to define which concurrent memory accesses are valid and how they interact. Otherwise you’re at the mercy of however the platform decides to flush caches that day.

I mean, of course you can just mandate sequential consistency everywhere and bloat your codegen in the process, but if you care so little about performance, why even bother with Hare? If I wanted a poorly specified, badly performing language with no concurrency support and a superficial appeal for simplicity, Python will suffice in the role.

No, Hare does not emit barriers around every memory access, but the programmer can add them where they want -- and there are no tricky compiler optimizations which will bite them in the ass when they do like this paper describes.

> I mean, of course you can just mandate sequential consistency everywhere and bloat your codegen in the process, but if you care so little about performance, why even bother with Hare? If I wanted a poorly specified, badly performing language with no concurrency support and a superficial appeal for simplicity, Python will suffice in the role.

This was not nice.

Despite being a huge fan of Drews work, I wasn't initially wowed by Hare but the more I see of it, the more interested I am. Really think I need to have a play around with it soon.

Reply on news.ycombinator.com