OSNews

The kernel handled multithreading pretty well. Not everything was perfect, but the issues were well-understood and were to be taken care of if Be had continued to focus on it (I can remember the issues of the giant semaphore spinlock, the giant vm lock, the giant loader lock and the single-threaded psycho_killer). One of the other Be kernel engineers implemented his own kernel on his spare time to experiment with solutions for some those problems, I remember discussing those quite a lot since we were living in the same house at the time (sharing houses was fairly common among Be engineers). The only other thing I'd have liked to see would have been an explicit mutex (as opposed to a semaphore) so that the scheduler could inplement priority inheritance, but once again there wasn't any fundamental issues that prevented from doing that.

There were a few issues with the way some user-space code used threading. One of them was related to the messaging code (BMessenger and BLooper), which by default gave developers lots of opportunities for deadlocks or lost messages. Another one was that the part of a BWindow that communicated with the app_server used exactly the same lock as the BLooper part of the same BWindow, causing lots of pain when porting software from other OSes. Worse, either of those issues could have been taken care of by developers (maybe with a bit of covoluted code), but the way they interacted caused lots and lots of problems, which (just like any threading issues) were often extremely hard to diagnose and/or reproduce. Even worse, solutions for those problems weren't straightforward to implement if Be wanted to maintain backward compatibility *and* and easy migration path for existing code.

Take all that with a grain of salt, I haven't really written any code for BeOS for approximately 5 years (my last 15-months-or-so at Be were mostly spent re-writing the Makefile system, which I was and am very proud of).