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 Sun 2nd Sep 2001 17:54 UTC

I've had a very interesting IRC chat yesterday with Kurt, during which we cleared out quite some misunderstanding, and analyzed the results that Kurt had seen. About the AtheOS app_server first : the app_server has to deal with various tasks that take some significantly different processing times. Passing a keydown event around will take a few microseconds, whereas doign a big (software) screen-to-screen blit can easily take hundreds of milliseconds. Processing all those sequentially means that the "small" events are slowed down by the "big" ones. About ABrowse : the HTML engine isn't thread-safe, and each instance of ABrowse can only access the engine from a single thread at the same time. When each window runs in a different process, the bahavior of each window is very similar to that of the app_server described above : calls to the HTML engine to parse and/or render HTML will slow down the passing of messages. Fortunately, this goes mostly unnoticed, as the windows stay independent from each other, and as it it pretty "normal" while using a browser to not use the window while it is parsing or rendering HTML (there's nothing to interact with at that point!). When all the windows run in the same process, things suddenly slow down. The major reason is that some small events that would normally be processed quickly but require to lock the HTML engine suddenly become much much slower, because they have to be processed sequentially with some long events. Interestingly, the "single-process" ABrowse still has one thread per window, as many as the one-process-per-window ABrowse, but is significantly less responsive, proving that one-thread-per-window doesn't automatically imply responsiveness. ABrowse feels slow when running all the windows in the same process, for several reasons : -because it processes small events and long events sequentially within the same window (even though this is not a major issue for a browser). -because, through the HTML engine, it processes small events and long events sequentially across windows. -because, since the big events have to be processed sequentially, it can't use the second CPU efficiently. There are a few ways ABrowse could be made more responsive : -If the HTML engine is kept entirely "as is", any event that needs to be processed through the engine should not be processed by the message loop itself, but should be deferred to a worker thread. -If the HTML engine can be made "a bit" thread-safe, such that a "small" event and a "big" event can be processed through it simultaneously, only the "big" events need to be deferred to a worker thread. -If the HTML engine can be made entirely thread-safe, it would be possible to have several worker threads to process the "big" events, where the number of such threads would be chosen relative to the number of CPUs. If would then be possible to achieve near-maximum responsiveness with a single message loop processing all the "small" events, and dispatching the "big" events to a pool of worker threads, where the number of threads would be chosen such that the (unix-style) load created by the worker threads would be equal or slightly greater than the number of CPUs. A few rules of thumb to choose how the threads should be chosen, assuming a reasonable level of thread-safeness : -A thread should not process messages that require different amount of time to be processed. Both I/O time and CPU time count in that case. -If an application is expected to have to deal with messages that take different amounts of time to be processed, it should have several threads (or pools of threads) each dedicated to processing messages that take similar amounts of time. -The number of threads withing each pool will vary depending on the number of CPUs and the kind of tasks that the threads are expected to have. A good rule of thumb is to try to keep the (unix-style) load approximately equal to the number of CPUs there are in the machine. -The priority of threads should be chosen such that the average likelihood of a thread being scheduled is inversely proportional to the time it takes to process the tasks that that thread deals with. --jbq