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 Wed 29th Aug 2001 17:57 UTC

Well, having multiple threads will always require some level of communication between them, there's no way around that. If the threads were totally independent, there would be absolutely no point putting them in the same applications ;) First, let's assume that threads are meant to maintain or improve responsiveness. From that point of view, solving a problem by "polling" (i.e. looping until a condition is met) is unacceptable, as it causes both CPU usage and delays. In any multithreaded system, data protection is an issue : because threads are asynchronous, some form of data protection must exist, to make sure that two threads don't access the same piece of data at the same time. As you explore real-world cases, you will quickly notice that getting multiple threads to access the same data at the same time causes some locking problems, quickly leading to deadlocks. A good way to deal with that is to use asynchronous communication between threads, which is what the BeOS messaging (BLoopers) tries to achieve. Asynchronous messaging, though, is fairly tricky to deal with. As a BLooper could be receiving messages from pretty much anywhere, and as the only way you can communicate without deadlocking is through asynchronous messages, the developer needs to keep track of the state of all the "communications" that a BLooper is currently processing. This kind of code is hard to write, and extremely hard to test thouroughly, as it is asynchronous by nature, and the number of possible states grows exponentially with the size of the data the BLooper deals with. Practically, BeOS makes all this even harder than it needs to be. BLoopers have a very primitive locking system (a single lock for the looper, automatically acquired before dispatching a message). For BWindows, it is even worse, because the same lock is used to protect the session between the interface kit and the app_server (which means that drawing in threads other than the main BWindow thread has some interesting locking constraints). Also, and that's probably the worst issue with BeOS, the kernel doesn't guarantee that it'll let messages go through, and the application kit doesn't do anything to work around that problem. A messaging system where messages aren't guaranteed to go through is a nightmare to deal with. And, finally, there's a big reason why I think that the BeOS "pervasive multithreading" is just smoke and mirrors. Developers know that, to keep an application responsive, BLoopers should all stay responsive, which means that they should not eat too much CPU power and quickly process and respond to messages. If BLoopers don't eat too much CPU power, they are not competing among themselves for CPU power, even on a multi-CPU machine, which means that they don't need to be running in multiple threads. Furthermore, the "responsiveness" that people are talking about is responsiveness of the UI. That can be split in two parts : the speed at which applications respond to input events, and the speed at which they redraw when windows are moved around. Big surprises here : there's usually only one mouse, only one keyboard, such that cases where several applications have to respond to input events at the same time are marginal, unusual cases. As for redrawing, all the redrawing events are sent to the graphics chip, which can only deal with one acceleration at a time anyway. I personally believe that a good level of responsiveness can be achieved with single-threaded applications, through the use of signals and asynchronous IO. Contrary to what people believe those don't make the applications harder to write, especially because people aren't forced to use them. In my opinion, seen from an OS designer's point of view, the BeOS way is a fairly lazy way to write an OS : force the developers to handle asynchronous events through threading, such that the core services of the operating system only handle synchronous requests. --jbq