Linked by Eugenia Loli on Mon 27th Aug 2001 05:22 UTC
Syllable, AtheOS AtheOS is a modern, free (GPLed) Operating System written from scratch in C++. A big chunk of the OS is POSIX compliant, supports multiprocessing and it is GUI-oriented (fully OOP). Today we are hosting an interesting interview with the AtheOS creator, Kurt Skauen. Kurt is talking about his views on binary compatibility in future versions, multithreading and the future of his OS in general.
E-mail Print r 0   · Read More · 53 Comment(s)
Permalink for comment
To read all comments associated with this story, please click here.
Re : Multithreading
by Jean-Baptiste Queru on Sat 1st Sep 2001 17:56 UTC

stippi : well, I like and dislike your post. I like it, because it is somewhat true that my previous posts go along the lines of "trust me, it sucks". I've had enough first-hand and second-hand experience with issues porting and/of developing code on BeOS to know that multithreading can be an issue. A few names just for fun : SimCity3000. Cycling74 Max. Macromedia Flash. Mail-it. Nuendo. bdb. In every one of those cases, the BeOS multithreading (multiple message queues with multiple messages being processed simultaneously) caused more problems than it created solutions. So, I think that you can indeed "trust me on that one". I don't like it, because I don't think that your argument holds very well when it comes to multithreading windows. For 3 reasons : -At some point, Be experimented with that problem, one of the paths that was followed was to make all BLoopers share the same BLocker. It created some obvious deadlocks (intra-team inter-looper synchronous messages), but many apps actually worked, and responsiveness was unaffected. -The graphics chip can't be shared by multiple threads. As a matter of fact, access to the hardware acceleration is traditionally restricted by a mutex (and, before you say that it's inefficient, well, it doesn't matter : filling the FIFO isn't the limiting factor). Access to the framebuffer is usually not restricted at the software level (except for lame-ass cards), but the hardware takes care of it. Experience shows that accessing the framebuffer from several CPUs at the same time doesn't improve the throughput (it could even have the opposite effect, especially with fast PIIs and above combine with fast graphics cards). -One of the big changes in the app_server between R3 and R4 was to make the locking inside the app_server more fine-grained. Interestingly, this made the machine feel quite slower. Owners of slow BeBoxes remember that time. I myself had my BeBos running R3.1 until fairly recently. As it turned out, the locking until R3 was so gross that no two app_server threads would ever try to touch the graphics card at the same time at all : the rendering part of the app_server was essentially single-threaded. And it was fast. OK, maybe the word "lazy" wasn't well-chosen. But many parts of BeOS never got the polish that would have been needed to make BeOS a better OS. That wasn't caused by laziness, but rather by lack of time, the list of tasks as hand being always so big that in many cases it was chosen to ship features that were 90% functional instead of spending twice as much time to reach 99% functionality. I would put the "one-thread-per-window" issue into that same bag : it just made it easier to write the app_server and the interface kit that way. And it is "good enough" for most situations. I could give other examples of issues where a "90% solution" was chosen, BeOS is full of those. --jbq