Slashdot Mirror
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?"
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.
||| I still can't believe Parkay's not butter.
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.
load "$",8,1
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.
Part of the problem is that Windows was originally a cooperative multitasking environment (like MacOS). When they added real threading (in Windows 95, I think), each application was still single threaded, which meant having the GUI and underlying processing on the same thread, making responsiveness sucky. 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).
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.
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.
Breakfast served all day!
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, 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).
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.
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.
Apple are adding the NSOperation and NSOperationQueue in Leopard to help with creating multithreaded applications. There's no public documentation on these yet, but based on what has been told in public it seems that it's mainly a worker thread API.
Let me know when a modern linux system can asynchronously notify a process that a file/directory has been modified.
You mean--like every one? Beagle uses it, and so does Nautilus. It's been there for a number of years.
If someone want to see BeOS and it's open source counterpart in action and you live close to san-francisco, try to attend waltercon 2007 in august http://haiku-os.org/ (registration are open).
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.
I believe the mere fact he mentioned the HURD is sufficient proof that he was not being serious.
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.
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).
Yes, I used it. I paid $100 or more for it if I remember correctly. I was very excited about it, thinking it would be really cool. It definitely had nice demos. I don't know why it didn't open a debugger when I got errors trying to use the modem. I really don't. Who knows, maybe it did, and I've forgotten - it was 8 years ago. But in any regard, whereas I expected to be able to find documentation on how to configure the modem, how to manually force IRQs and DMA addresses and stuff, I found nothing. If it wasn't covered by one of the few GUI controls for that particular device, I couldn't do it. I gave up.
...
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
I realize that I may be treading on shaky NDA ground, but I can say that Leopard makes some serious advances in this respect. I don't know if QuickTime and AppKit are fully multi-threaded yet -- but I can say that they seem to be a hell of a lot closer than in Tiger. Also, xnu has had a HUGE amount of work put into it in an effort to reduce locking situations, and it seems to have paid off -- a lot of stuff that would cause a UI hang in Tiger is no longer an issue in Leopard. It also seems that CoreVideo/CoreAnimation have been written with SMP situations in mind.
That's about all I can say without the black helicopters descending on^NO CARRIER
The real litigious bastards...
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.
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
Apple spoke about multithreading in last year's WWDC "Mac OS X State of the Union" session. Apple provided a recording of that session (among two others) for free though iTunes. Since they're free, I uploaded a short clip. Once Veoh encoded that video, it will be available at http://www.veoh.com/videos/v801272G85gFFER.
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 Macs had a horrible lack of multitasking that the Amiga had, certain x86 operating systems at the time allowed multitasking, but were really bad at it.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.)
the more advanced Amiga hardware was far cheaper.It's too bad the company was sucked dry from within, and there was virtually no advertising.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"