A few months after my contract with Haiku, Inc. began, I rewrote the implementation of the Haiku kernel’s condition variables (as opposed to our userspace condition variables, which are from POSIX.) As this new implementation has run in Haiku for over a year and shipped in the latest release with no sign of any remaining issues, I figured it is high time for a deep-dive on the API, its implementation history, and the design of the new implementation I wrote.
I expect this article will be of broader interest than just to Haiku’s community, because Haiku’s condition variables API has some notable (and powerful) features not found in those of other operating systems, and its implementation is thus likewise unique (at least, as far as I have been able to figure out.)
I’m currently working on a “state of Haiku” sort of article, and I’m incredibly impressed with just how stable, fast, full-featured, and usable Haiku has become on real hardware. I’ve always kept an eye on Haiku in virtual machines, but now I’m running it on real hard hardware – where it belongs – and it’s been an absolute joy.
The fact that waddlesplash managed to pull off this switch basically without any issues and with few people noticing, is further illustration the project’s in a good place.
I’ve said it before and i’ll say it again. Part of Linux’s lack of mainstream adoption is a complete lack of standardisation. Sometimes too much choice is a bad thing.
Haiku, being a complete OS from kernel to userland, doesn’t suffer from this. You don’t have to worry about if you’re running RHEH, or Ubunku, or Arch Haiku. Haiku is Haiku, just like Windows is Windows, or MacOS is MacOS. This completely integrated experience makes porting apps, distributing binaries, and most importantly, end user support much more streamlined and easier.
Therefore, i stand by my belief that if any FOSS operating system has a chance against Windows or MacOS, it’s Haiku.