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.
Confusing problems
by Jon Tidswell on Fri 19th Oct 2001 16:00 UTC

1) Multithreading is just an event handling system where there kernel provides various message queues. It gets most "useful" with preemptive scheduling. This can all be implemented manualls if you feel like it. [ Prof. N Wirth wrote a very readable paper against MT years ago. ] 2) Async IO is multi-threading with second class threads and a very inflexible scheduler. If you don't carefully lock data structures then the IO handler can access inconsistent data structures, if you do lock them then youve just (loosely) synchronised your async IO handler. :-) 3) There is no such thing as async messaging. The appearance of Async messaging is achieved by having a queue managed by a separate (and synchronous) worker thread enqueue and dequeue messages. The policy used by the worker thread to handle full queues is important. If the policy is to drop messages, and the worker thread is buried in the kernel and the policy is hard coded in the thread, then you end up with an unreliable OS. 4) Having the kernel allocate message queues is a _bad_ idea, it makes proper resource accounting very hard. I believe the late Prof Jochen Liedtke was correct in his L4 kernels in choosing only sync IPC. However I believe he was mistaken in not providing a semaphore for shared memory synchronisation. [ Note MS Windows has both PostMessage() and SendMessage(), the later is at least partly synchronous. ] 5) Synchronous messaging (and a predicatable scheduler) makes debugging easier, as it is possible to predict what happens. 6) Handling locks is tricky, which is why well designed languages provide high level synchronisation primatives where the compiler can verify many basic properties (e.g. locks get unlocked), and where code analysis can verify several more (e.g. consistent nesting) allowing formal analysis of deadlock freeness (what a word :-). 7) The idea of separating UI code from application code is not new. Its just a shame that X did not include a proper extension mechanism.