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.
Permalink for comment
To read all comments associated with this story, please click here.
by Kurt Skauen on Sat 1st Sep 2001 20:08 UTC

JBQ, You seem to make a few assumptions that dont really hold. When I first implemented memory-protection in AtheOS I had to make a server that dealth with the GUI (or put it in the kernel but that was never an option). The first version of AtheOS with memory protection (each process running in a separate address space) did not have support for multiple threads per process so the server had to be single threaded. I later added support for multithreading and rewrote the server to use one thread per window and boy did the responsiveness increase! Even with the rude locking schemes I had in the first version of the multithreaded server the sensation of speed-increase it gave was stunning. This was of course long before AtheOS got support for SMP and there is no doudth in my mind that the number of clock-cycles needed to update the screen after moving a window increased quite a bit when introducing multithreading but still the fact that certain operations got attention a bit earlier made the OS feel *so* much more responsive. Even though I only had one mouse. The same goes for multi-window applications. Like I mentioned ABrowse is essentially single-threaded and it can open multiple windows. Just out of curiocity I opened 10 browser windows using a single instance of ABrowse on one desktop and then started 10 instances of the browser on another desktop. All browser windows displaying the same web-page. I would not have any problems passing a "responciveness blind test" between the two desktops ;) The fact that more finegrained locking made BeOS run slower on a BeBox does not surprice me one bit. The PPC's in the BeBox was not designed to run in SMP. Be threw away the second-level cache and added a second CPU instead. The L1 cache syncronization model this gave caused a *lot* of cache flushes essentially halting the CPU's when the two CPU's was working in the same memory area. CPU's designed to run on SMP boards have much better characteristics in this situations. I would not be surprised if ripping one of the CPU's out of your BeBox would also speed up certain operations. At some point in a not to distant future I will add support in the kernel for a generic "wait for multiple event" kind of call almost like select() but that can wait on all kind of objects (pipes, sockets, message-ports, semaphores, thread-deaths, etc etc) and that have a register-object/unregister-object type of functionality so not the entire list of objects have to be passed to the kernel each time you want to wait for a set of events. I have often been thinking about using such a system to allow multiple loopers to be run by one thread. Either by making it possible to link loopers together or by having another kind of thread-object that you can add loopers to instead of Run()'ing them. I can absolutely see that this would be of great help for porting single threaded applications but I'm very reluctant to make it "to easy" to write single threaded applications under AtheOS since I have first-hand experience with how much multithreading increase the responsiveness of the GUI. Kurt Skauen