Will Pervasive Multithreading Make a Comeback?

exigentsky writes "Having looked at BeOS technology, it is clear that, like NeXTSTEP, it was ahead of its time. Most remarkable to me is the incredible responsiveness of the whole OS. On relatively slow hardware, BeOS could run eight movies simultaneously while still being responsive in all of its GUI controls, and launching programs almost instantaneously. Today, more than ten years after BeOS's introduction, its legendary responsiveness is still unmatched. There is simply no other major OS that has pervasive multithreading from the lowest level up (requiring no programmer tricks). Is it likely, or at least possible, that future versions of Windows or OS X could become pervasively multithreaded without creating an entirely new OS?"

Comments

It makes sense with multi-core cpus

[Thaidog]

OSes like BeOS and Zeta are ahead of their time. With 8 core cpus coming out soon it just makes since with this technology... no programming tricks are needed.

Re:It makes sense with multi-core cpus

[tolan-b]

Haiku is coming along very nicely though, and it's open source.

Re:It makes sense with multi-core cpus

[dlockamy]

huh? what BeOS are you talking about?

libroot was in C, the api was all c++, but there was still a nearly posix subsystem in place via libroot.

Re:It makes sense with multi-core cpus

[Carewolf]

KDE/Qt has that nice signal/slot thing, it must be easy to write that in a way that makes use of multi-cores.

It is! In Qt4; it has transparent thread-safety across signals and slots, making it very easy to write multithreaded Qt4 applications. KDE is a little behind, but KDE4 is still going to be more multithreaded than KDE3.

Re:It makes sense with multi-core cpus

[man_of_mr_e]

There are many factors that define the performance of an OS. One of them is the number of features it provides, and another is the timetable in which said features are delivered. Yet another is legacy compatibility.

BeOS was new. It didn't have to be compatible with anything. But give it 10 years, and 2 Gazillion hacks to let old software continue to work. Give it hundreds or thousands of features, many of which are probably no longer even used by many people, but still have to be there because some small subset needs them. Give it features built upon other features and security patches upon other patches.

Commercial software vendors seldom have the ability to ship software when it's ready, they have to meet timelines. Look at OS X, each new release cycle takes longer and longer because as the OS matures, it takes more and more time to wade through the existing code to change it. It gets slower because more conditionals have to be added to check for compatibility or security issues, or because it needs to do more than it used to.

Linux (the kernel), on the other hand, seems to get better and better, faster and faster, with each new release. There is a reason for that, though. No commercial pressure to release, they can set an arbitrary release date and simply ship whatever features are ready, and do so relatively frequently because they don't have to worry about a large and complete OS release, just the kernel.

Distro vendors, on the other hand, seem to be taking longer and longer between releases (not counting Debian, which has always been glacial), because as the body of software grows, it takes more and more work to maintain it. Distro quality depends largely upon how long they spend stabilizing releases.

Better than xubuntu

[fishthegeek]

for older (p2 & p3) laptops. I have the opportunity several times a year to receive old laptops to use to teach my students with. Whenever I need to I use Beos Max on the machines and it is just amazing to watch how effecient and responsive Beos really is.

Check out Beos Max

Beos is still a lot of fun on older hardware.

Amiga beat them all

[Anonymous Coward]

Serious back in the mid 1980's I used to love putting PC and Mac owners to shame by showing them literally dozens of open, active graphics applications displaying animations, while formatting a floppy disk, and downloading a file online, and still having a normal responsive system with no hic-ups, all in a computer with on 128MB RAM.

Amiga was a multi-tasking, multi-threaded OS, with multiple processors (graphics and I/O were separate co-processors operating on opposite clock cycles from the CPU, and the graphics co-processor could be dynamically loaded with special executable code).

It was so far ahead of it's time that people today still don't believe it existed in the 80's when I tell them about it.

But just because it was better than everything else did not assure it's success. A concept the BeOS fanbois might be familiar with.

Re:Amiga beat them all

[GreggBz]

Hey, I'm all for Amiga's but in the mid Eighties, if you had 128MB of ram and was downloading a file online, you must have been from the future.
What the heck are you talking about?

Just to be a little more correct here, I'm no hardware engineer but will try to be far more accurate.

The Amiga had a great messaging system in it's OS, you could easily pass messages to other windows and programs in intuition. Further, you had all that ARexx stuff, and you could script programs to interact very easily with it. Basically, every program could listen on it's own ARexx socket for commands from other programs. Of course, there was the poor (read, no) memory protection which made things very unstable if you did not know what you were doing. Despite all this cool stuff, the OS was actually the weakest link. It was rushed. I remember reading specs on the original intended, but non-implemented file system, and it was about as robust as a single user file system could possibly get.

You also had preemptive multitasking (not true co-operative) and a fantastic unified memory architecture with a very fast blitter. Another nice thing was
that the kernel was contained on ROM so that it booted quicker then any other platform of it's day, and still faster then most this day. And all those chips played nice
and were synced to an internal clock that ran on NTSC (or PAL) timings. This, of course, meant that interrupts worked seamlessly, and the chipset was handily compatible with video signals from television equipment. That last thing turned into an incredible boon for the entire film and television industry.

The strength of the Amiga was it's bus and it's architecture. They absolutely nailed so many things in it's design, it really was a thing of beauty.

Re:Amiga beat them all

[Anonymous Coward]

Corrected the memory size in another reply. The base system had 256KiloBytes of RAM. Sorry for the mix up, I'm so used to putting MB after memory sizes. ;-)

As for downloading files online, back then "online" meant downloading from BBS systems. The closest thing to the internet back then for the average consumer was FidoNet.

http://en.wikipedia.org/wiki/Fidonet

And yes, the lack of an MMU, as well as a lack of FPU, in the CPUs used in the early models was a shame. But it did keep the price of the system within reach of the average Joe Computer Geek.

Re:Amiga beat them all

[wall0159]

"128MB? In the mid 80s? Maybe you mean 4Mb :-)"

Actually, I think the GP probably meant 128KB.

My parents bought a 486SX33 in 1994, and that had 4MB, but in 1985....

Re:Amiga beat them all

[DusterBar]

From today's perspective (and even 10 years ago) the Amiga has many limitations. But lets not forget that the Amiga started over 20 years ago! (Boy, I must be getting old...)

Multi-threaded programming was a core feature of the Amiga. The UI, Filesystem, core input management, sound, etc. All were managed via threads. This is what allowed some of the very smooth behaviors that so many still talk about today. (Albeit with some rose colored glasses)

Yes, multi-threaded programming is hard for those who learned with BASIC on C64/Apple-II and MS-DOS environments. But that does not mean it is (or was) fundamentally hard. It just takes a slightly different mindset and approach.

There are many times I had wished other platforms had good multi-threading. After leaving Commodore-Amiga, I actually built/designed something known as MMOS on top of which Scala technology then moved to. Multi-tasking/multi-threading makes some of the harder problems just so much easier to solve. (Especially in event-based or near-real-time systems)

I am generally amazed at how many people have difficulty with the multi-threading concept. I was amazed back then and even more so now. One time, I worked with a 3rd party ISV to help them with some software design of a game for the Amiga. They ended up really "getting" the treading concept, so much so that they had to write their own threading OS layer on top of DOS in order to port the game to MS-DOS. (A hockey game where each computer player AI ran in its own thread and the display thread did the coordination of behaviors - it was a great game for its time).

BTW - The entire AmigaOS software team could fit in a single van (and did a number of times when going out to events). (Ok, a large van, but still a van). Our whole team was less than 1/30th the size of the Apple OS team in the late 80's and an unimaginable amount less than the Microsoft Windows team. As far as slow/late software upgrades - the AmigaOS 2.0/2.04 software upgrade was a long time in coming as the target kept moving and we had this "99.99% compatible" requirement, even for software that was doing silly things like assuming certain values in undocumented OS data structures. Even so, the upgrade was only 16 months late relative to the initial target date, of which 6 months was trying to convince the marketing department that they should actually sell the upgrade. (They thought that the Amiga was not worth doing upgrades - users should buy new ones)

-- ex-Commodore-Amiga OS Systems Engineer (Exec/Expansion/680x0/Audio/Layers/Workbench/IEEE/ etc.)

Re:No Maybe Yes

[someone300]

X is being fixed, thankfully (finally). There are a lot of interesting projects, including but not limited to Xegl. Xegl, is the long term goal of the X server and pretty much reduces the X server to a tiny part of the system, basically mediating the input devices, rotation and display management and TCP/over-the-wire GL, if I understand correctly, by using the Embedded GL specifications.

Re:Multithreaded won't be optional any more.

[nomadic]

current Linux desktops seem very responsive even when running multiple apps

I'm guessing you never used BeOS; by comparison Linux looks weak in terms of responsiveness.

Re:BeOS was awesome

[drinkypoo]

Quit pretending that it was ever a viable OS or that it is anything special nowadays. Yeah, yeah, it could run multiple videos at once. But then again we're talking multiple 160x120 videos because that was about as good as video got at that time.

Speaking of tech demos, the "book" demo where you put four quicktime movies on the pages of a book and flipped the pages with the mouse, did you ever see that? On a 66MHz BeBox (dual 603e, hardly a speed demon) you could have four 320x240 (biotch!) videos playing on this book. Well, you could only see two at first. But then you flip the page around as you like with the mouse and you can see (part of) four videos playing at once. And the whole thing was quite smooth. The framerate would sometimes degrade but the page still moved smoothly and the rest of the OS was still responsive.

That was the one that really impressed me. They obviously really cared about responsiveness in a way that no one else seems to.