Linked by Thom Holwerda on Sun 10th Jul 2011 18:50 UTC, submitted by moondevil
Microsoft "The Microsoft and ETH Zurich research teams have published the source code of Barrelfish, a multikernel operating system for the multicore heterogeneous hardware of the future. Today's operating systems have been adapted to work on multiprocessor and multicore hardware, but they were not initially designed with multicore in mind, and they are not ready for heterogeneous hardware with hundreds of cores that is to come in the following ten years. The main problem is the concept of shared-memory and the contention arising from accessing the same data protected by locks. This is the problem that Barrelfish wants to address."
Permalink for comment 480275
To read all comments associated with this story, please click here.
Member since:

Except one doesn't actually need that many since they spend 90% of their time idle. As stated, it is simple fact that BeOS is done the way it is because of those kernel limitations, the app_server engineers didn't want to have to design it that way because it caused various other problems, such as the fact that one couldn't have more than 192 windows at most, fewer than that if off-screen bitmaps are in use. A design using one or two threads watching the ports + a thread pool to handle the actual worker operations would have scaled significantly better (and been just as responsive), but that wasn't possible owing to the aforementioned kernel limitations.

I don’t think these facts prove your point that BeOS is the same or less responsive to user interaction than Windows. The rationale for why it was designed so doesn’t disprove my assertion that having more threads in an app makes it more responsive under system load. I don’t think having a limitation of 192 windows seems like much of a problem. It think hitting this limit under normal use in the year 2000 seems unlikely. You point out interesting kernel limitations in BeOS, certainly you have done some homework. But this doesn’t give credibility to your point that BeOS is not more responsive than Windows.

Except nothing about that design implicitly leads to more responsiveness for the user, that's more a matter of how you handle locking for the various GUI/input operations. And nothing stops one from spawning off threads to perform things like blocking I/O operations, that's basic software design.

I agree that this is software design, but I disagree that you find this design frequently in Windows apps. Although one can spawn off threads in Windows apps I do not think it commonly done. The example I gave on another forum is streaming a Netflix movie on Windows using the Chrome browser. Lots of apps lock up including Chrome, and Chrome is supposed to be multi-process. If you read through the BeOS development materials they constantly tell you when to multi-thread your applications and IO. It is highly encouraged and not generally difficult to do.

A BeOS window will block just as badly as a Windows one if you try and do I/O from the window looper thread (and quite a few apps on bebits do exactly that), seeing as the app_server threads won't do much of anything without the window sending them drawing commands.

There are many poorly written apps on BeBits and Haikuware. On a well-written app it is less likely to happen. If an app developer spent any time testing an app that blocked on IO, causing the entire app to block, it would be easy to fix this.

BTW, thanks for sharing your points. From this exchange I am actually learning a bit of BeOS kernel history.

Reply Parent Score: 2