OS Multi threading differences

Question

I'm asking this question because I was investigating the Haiku OS (a BeOS descendant).

The goal of the BeOS operating system was to create a desktop environment that handles multimedia well and is very responsive. They manage this by creating a kernel that has "pervasive multi threading".

Other operating systems (Linux, Windows etc.) don't have this "pervasive multi threading" and hence, aren't that responsive. (no flame wars please...)

Could someone explain the (subtle) differences between the "pervasive multi threading" (like in BeOS/Haiku) and the multi-threading used in Windows or Linux?

What are the implications for a developer for the different multi threading systems?

---

I found an interesting site about BeOS Multi-threading... BeOS Multi threading

Answer 1

Copied from an answer I made for the now closed question "What is/was so terrific about BeOS [closed]", but applies here quite nicely:

From memory, the odd thing about BeOS development is that the GUI really is multithreaded, unlike GUI frameworks on other platforms, which tend to be absolutely single-threaded.

This meant that developing GUI applications for BeOS is completely different, but I assume that this meant the GUI's were more responsive, without requiring explicit design at the application level for handling GUI interactions.

Of course, this does mean that using mutexes and the like are more important, and porting GUI applications from other OS's to BeOS are difficult unless the BeOS GUI library is effectively turned into a single-threaded library by using and enforcing a single application-wide mutex.

Linux, Windows, and almost all other OS's I can think off that I've used in the past decade support multithreading, Linux and windows both which utilise multithreading in substantially different ways but do so very well - however, BeOS really uses multithreading pervasively - and this is made obvious by, eg, the GUI framework, whereas most others are strictly single-threaded. (Or, at the most extreme, permit multiple threads from access with undefined consequences...)