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."
Thread beginning with comment 480272
To view parent comment, click here.
To read all comments associated with this story, please click here.
AndrewZ
Member since:
2005-11-15

I am afraid that we have a difference of opinion on this matter. Here are the facts, not marketing cool-aid: Each BeOS/Haiku GUI application has in fact 4 threads. One in the application BLooper, one in the Window BLooper, and two in the servers to process the BLoopers. And you can easily add more threads if you want them. This is a design that leads to greater responsiveness. This is a simple matter of OS design principles that you learn in university.

A standard Windows application has one single thread. This thread is often blocked by IO operations such as access to a CD, a network operation, a slow disk, or dialog operations. By this design, a basic Windows application is also single core. This is a design that leads to less responsiveness to the user.

I have done more than just repeat what others have said. I am in the process of writing apps where performance can be measured. I really have no interest in banging the drum for dead companies where there was no innovation. I really am interested in the innovation and what makes Haiku different.

Reply Parent Score: 1

anevilyak Member since:
2005-09-14

I am afraid that we have a difference of opinion on this matter. Here are the facts, not marketing cool-aid: Each BeOS/Haiku GUI application has in fact 4 threads. One in the application BLooper, one in the Window BLooper, and two in the servers to process the BLoopers. And you can easily add more threads if you want them. This is a design that leads to greater responsiveness. This is a simple matter of OS design principles that you learn in university.


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.


A standard Windows application has one single thread. This thread is often blocked by IO operations such as access to a CD, a network operation, a slow disk, or dialog operations. By this design, a basic Windows application is also single core. This is a design that leads to less responsiveness to the user.


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. 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.


I have done more than just repeat what others have said. I am in the process of writing apps where performance can be measured. I really have no interest in banging the drum for dead companies where there was no innovation. I really am interested in the innovation and what makes Haiku different.


Except you haven't, every single comment you've ever posted in this vein is the epitomy of the stereotypical clueless BeOS fanboy, as is your response here.

Reply Parent Score: 2

AndrewZ Member since:
2005-11-15

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