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.

I've spent he bulk of my career working in Windows and OS/2, so my perspective on the MT issues addressed so completely by both Kurt and JBQ are probably a little different. <p> The problem as I see it is that MT is percieved as a 'quick' answer to providing UI responsiveness. This is fairly accurate, but it's got nasty ramifications. Most code has a pretty specific flow. In the case of Windows and OS/2 everything runs in a single app, uses a single thread by default. Under NT that changes marginally, but it's more of a semantic change than a functional change. Those of you that have used Windows XP will have noted that Console Windows are not themed, the semantic change doesn't effect them, they run in a single thread :-). The nasty ramifications are that communications between threads become unreliable without significant efforts to prevent this. In Windows, I personally go out of my way to implement threads only where appropriate, ie, when you start an application, run the UI on the default thread, creating windows, populating them, arranging them etc. This can take a while in a complex application, think Productive or the defunct e-Picture startups. During that time, it makes sense for the other long running processes that run in that time to be doing other things on other available CPU's, in my case I do alot of DB related work, so I have the data access running in it's own isolated thread. When that data thread returns, I need to then push the data from the thread into the UI thread. That means synchronization. Lock the UI thread and post the data. Let's say the JBQ's issue of dropping a message because of poor system conditions occurs. The customer experiences Data loss, the app loses data integrity, and the user experiences a 'bug', one that I as the developer cannot reliably reproduce, and therefore almost any fix I put in place is pure guesswork.<p> How real is this situation? Very.<p> There are several solutions out there. I'm not going to come off the fence and say that any one of them is better than the other, but for grins I will let you in on one of Windows dirty little secrets. Windows does COM and DCOM via Window Messages and DDE behind the scenes. It's all smoke and mirrors too. Along the way, the learned that the Single Input Queue that OS/2 had created 'perceived' lockups when the system was still in fact functioning (but an app wasn't clearing it's message que), so they used mutliple ques, and in Windows there are literally hundreds of invisible little windows handling COM / DCOM messages in thier own little asynchronous ques to make inter-process and inter thread communications easier and more reliable.<p> In other words, while I love the BeOS, I find it MT to be massive overkill to a problem that wasn't that severe. dru