Will Pervasive Multithreading Make a Comeback? 657
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?"
It makes sense with multi-core cpus (Score:5, Informative)
Better than xubuntu (Score:4, Informative)
Check out Beos Max [beosmax.org]
Beos is still a lot of fun on older hardware.
Re:It makes sense with multi-core cpus (Score:5, Informative)
Amiga beat them all (Score:4, Informative)
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:Microsoft's plan is to keep adding cores... (Score:3, Informative)
My experiences with Linux show it suffers big time from process hogs, especially IO process hogs, such as when you copy large directories, even with the low-latency desktop kernel options enabled, so don't think it's just a Windows problem.
Re:Threading isn't any easier when it is pervasive (Score:3, Informative)
Really? Man, tell that to my box running Vista Media Center. Media Center has a helpful (cough) habit of capturing the mouse cursor to the screen running the Media Center app. Hit the Windows key to break out of it and your video playback is interrupted for as much as 20 seconds while Windows struggles to switch screens and render the Start menu. What's more, despite the fact that Vista has been re-engineered to support multiple sound output devices, it is not possible to assign one particular device to Media Center. In other words, you cannot force Media Center to always use your SPDIF output for sound and then use the computer speakers for other apps. You MUST specify SPDIF as the default sound device for the entire OS if you want Media Center to output sound in that way. It's clear that, for as powerful and multi-thread capable as modern hardware may be, Vista Media Center was written with the assumption that your PC will become a single-purpose appliance. It's kinda pathetic.
Re:Multithreaded won't be optional any more. (Score:3, Informative)
So, I am not convinced a rewrite of an OS just to add pervasive multithreading is a good idea. Anyhow, for those interested in that concept, there is Haiku [haiku-os.org], which is the FOSS OS inspired by BeOS. Looks like they are making nice progress (but nothing you'd want as your main productivity OS just yet).
Re:No Maybe Yes (Score:5, Informative)
Re:Amiga beat them all (Score:5, Informative)
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 (Score:3, Informative)
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 [wikipedia.org]
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:Puh-lease (Score:2, Informative)
gcc does thread-safe initialization of local static variables -- Visual C++ does not.
VC++ does do threadsafe static initialization. And in any case, gcc runs on windows so it's not exactly a windows issue is it?
Windows has better support for multithreaded apps, it has a far richer set of thread/process synchronisation objects (mutexs, critical sections, semaphores, alertable wait states, events) than unix does.
Now, as far as 32k 'busy' running threads leaving the machine still responsive... let's just try that out..
DWORD WINAPI Th(LPVOID){ while(true); }
int main(int,char**) { DWORD id; for(int n = 0; n < 31999; n++) { CreateThread(0,0,Th,NULL,0,&id); } while(true); return 0; }
And I can report that yes, you're quite right, Windows is pretty much killed stone dead running these two lines of code. I'd love to hear a report from how Linux does running the equivalent.
Re:Not gonna happen on Mac until... (Score:2, Informative)
Re:I don't get it (Score:3, Informative)
You mean--like every one? Beagle uses it, and so does Nautilus. It's been there for a number of years.
WalterCon (Score:1, Informative)
On the subject of multithread, it could be interesting if individual or computer store could bring some mad hardware for testing purpose. The amount of knowlegable folk present + the usual casual feel of the event would make that very possible think.
Re:Question... (Score:3, Informative)
Re:Multithreaded won't be optional any more. (Score:3, Informative)
I'm guessing you never used BeOS; by comparison Linux looks weak in terms of responsiveness.
Re:Microsoft's plan is to keep adding cores... (Score:3, Informative)
They never bothered making the OS interface (Explorer) multithreaded, which is why on XP you can still crash Explorer and thus your entire desktop (although Explorer restarts after a few seconds).
Explorer has been multithreaded, well, basically forever. Certainly since at _least_ Windows 2000 and I'd happily wager since Windows 95 and NT4. P>The reason your Desktop disappears if Explorer crashes is because it's Explorer that is responsible for drawing the Desktop (and the Taskbar/Start Menu).
Re:It makes sense with multi-core cpus (Score:3, Informative)
libroot was in C, the api was all c++, but there was still a nearly posix subsystem in place via libroot.
Re:I hope so (Score:3, Informative)
Maybe there were workarounds that I didn't know about. I am not sure. All I know is I was never able to figure it out, and I went back to Linux in a hurry. It's possible that the problem was with me and that BeOS was an absolutely perfect, completely polished and bug-free product. People seem to be suggesting that's so. But my vote is "not worth it", and apparently the market agreed with me
Re:Not gonna happen on Mac until... (Score:3, Informative)
That's about all I can say without the black helicopters descending on^NO CARRIER
Re:Amiga beat them all (Score:4, Informative)
Actually, I think the GP probably meant 128KB.
My parents bought a 486SX33 in 1994, and that had 4MB, but in 1985....
Re:Proof MS set computer industry back (Score:3, Informative)
It wasn't until MS-Windows 2k that MS-Windows was even close to NeXTStep in features, and the cost was a lack of simplicity.
Depends on what you're measuring. NT had (still has, comparing to OS X) better internals - SMP, fine-grained locking, etc, etc.
Re:It makes sense with multi-core cpus (Score:3, Informative)
This is incorrect -- kernel code under BeOS was written in C. It was possible to use C++ in BeOS kernel mode code if you knew what you were doing and what to avoid (e.g. exceptions) but it wasn't recommended.
If you wanted to write a decent userland app in BeOS, OTOH, C++ was your only real choice.
Re:Amiga beat them all (Score:3, Informative)
Re:It makes sense with multi-core cpus (Score:4, Informative)
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:Ummm... (Score:1, Informative)
This is something of a confused summary. You make it sound as if constructs like locks are hacks to get around the lack of memory isolation in multi-thread applications. That's not true at all. Locks, mutexes, and other synchronization constructs are necessary to synchronize access to memory under all circumstances where multiple execution contexts (that is, multiple threads or multiple processes) share data. A multi-threaded application can be designed to avoid sharing memory just as much as a multi-process application can, and as a result, it won't need locks. Likewise, multi-process applications can share data (for instance, using POSIX shared memory), and when they do, they aren't off the hook for locking because they don't use threads.
Also, your statement that "Threads are actually a step backward from a reliability/security standpoint," makes no sense to me. You might be conflating the difference between shared memory concurrency and other ways of writing concurrent programs with the difference between processes and threads. I'm sure many people argue that shared memory concurrency is unreliable and potentially insecure, but that's not because of threads.
In fact, the difference between processes and threads is a subtle one. Neither term has a definitive meaning (they are not theoretical computer science constructs). The definition of a process and of a thread depends on what system you're talking about.
--Justin
Re:Not gonna happen on Mac until... (Score:3, Informative)
Re:It makes sense with multi-core cpus (Score:5, Informative)
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.
Re:Amiga beat them all (Score:3, Informative)
Re:Amiga beat them all (Score:3, Informative)
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:It makes sense with multi-core cpus (Score:3, Informative)
As I've understood it, X is simply a protocol, and the X server itself could be single- or multithreaded. That the current ones aren't (?) is simply an implementation deficiency.
Re:Amiga beat them all (Score:1, Informative)
Re:The Intel vs. Motorola Decision (Score:3, Informative)
The Amiga had a custom design that wouldn't scale. It needed new, custom hardware for each processor revision for the hardware to keep up with the processor. Eventually the Amiga got accelerated graphics cards and storage host adapters and the main system basically handled peripherals and sound.
The Amiga was a microkernel-based system which worked efficiently because it had no memory protection. It was an explicitly single-user system (hacks came out eventually to provide multiuser functionality, permissions, etc etc, but without memory protection it's all just jerking off really) and while it is capable of performing modern tasks it has serious deficiencies. It was totally excellent for its purpose at the time, but it just isn't practical today (except perhaps for PDAs and such, where I'm surprised not to have seen it.)
It's too bad the company was sucked dry from within, and there was virtually no advertising.
Re:BeOS was awesome (Score:4, Informative)
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.
Re:Amiga beat them all (Score:3, Informative)