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?"

It makes sense with multi-core cpus

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

too true. The linux kernel beats the beos kernel in threading benchmarks, but the entire Be OS GUI stack (kernel, display, windowing, controls) were designed with multithreading in mind. X/KDE/GTK et al are relics based on 1986 era computing.

Re:It makes sense with multi-core cpus

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

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

Re:It makes sense with multi-core cpus

Haiku from BeOS
Multitasking all programs without delay
Open source victory

Re:It makes sense with multi-core cpus

Five, Seven, and Five That's how a Haiku should go Not like you did it

Re:It makes sense with multi-core cpus

Good job I am a software developer and not an English teacher isn't it?

I don't think so.

Re:It makes sense with multi-core cpus

Seven syllables
Not seven? so use gzip
compress the fucker


;)

Re:It makes sense with multi-core cpus

You were allowed you to graduate...

Hahahahah! I found an error in your grammar rant, now you look even stupider than the guy you were trying to talk shit about. How does that feel you pedantic ass?

Re:It makes sense with multi-core cpus

Haiku samurai
Shows us all how it is done
Educational.

Re:It makes sense with multi-core cpus

I don't understand this logic that a "full featured" operating system has to be slow. What the hell are you OS designers doing that's eating up all the juice ? Just because Windows XP preloads a gazillion binaries doesn't mean it's a good idea.

An operating system's job is to mediate access to hardware and software resources. The fact that every modern OS is madly bloated is just proof that the world's OS developers are ADHD suburban twits getting lazy and gratuitous with fluffy GUI features, when really they should be focusing on two core things: device drivers and the almighty scheduler.

Just think about it: Windows Vista is, on average, 10% slower than XP for generic tasks and gaming. Why the hell is that ? Someone fucked with the kernel and stuck things in it that don't belong there, like that ever-annoying popup security model.

It's like any other optimization job: you tighten the hell out of the most frequently-called code snippets like the scheduler and memory manager. If your scheduler is so contorted and polluted that it can't even fit in the L1 Cache anymore, you should be beaten with your keyboard!

The BeOS guys probably had a plan, along with some good brains and coding skill, and they stuck to that plan. If a feature isn't in the plan, it doesn't get coded; the system stays lean and fast, and you let the application developers handle all the shiny stuff. That's how it used to be, and still is in some circles... but not Windows nor Linux. That's where we went wrong.

Re:It makes sense with multi-core cpus

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.

Re:It makes sense with multi-core cpus

".. it was more due to the fact that BeOS had very little capabilities that were tying up its resources. "

Oh bullshit. Perfect timing as well. Not five minutes ago my work desktop locked up for 45-60 seconds opening a simple HTML e-mail in Outlook and XP. As has been depressingly common with Windows for ages, having difficulties finding a remote source it simply ignored user inputs to concentrate on a network task presumably requiring well under 1% of the hardware's capabilities. Every Outlook window became unresponsive, as did server-hosted toolbars, etc.. These are architectural design decisions, not 'features' cutting off the use, unless 32-bit colour is now an extreme Windows desktop feature.

That's nothing...

Back in the OS/2 days, we could format 72 floppies simultaneous with no slowdown to our 14.4 connections!

Amiga beat them all

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

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

Re:Amiga beat them all

"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

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

Apart from the corrections already brought up, the Amiga was rife with limitations and problems of its own. It worked great in the narrow range that it was designed for, but had all kinds of other issues. For example, upgrading the video was a hack job that usually require patching the ROM libraries with ones that new about the new video hardware. It was tightly integrated, which meant doing anything outside what it was designed for was often difficult and expensive.

And I was an amiga fanatic. And, while I held out hope that Commodore would get their act together and provide the features that were rumored and needed (DSP's, retargetable graphics, etc..) I always knew it would never happen. If only Dave Haynie had been allowed to do what he wanted, but then again that probably would have made it too expensive for people to buy.

Re:Question...

BeOS was like JFK.

The both got gunned down before we could possibly see any downsides to them.

There were a few architectural decisions in BeOS that I felt would have resulted in great amounts of pain and suffering 10 years later.

Re:Question...

I believe that's covered by "There were a few architectural decisions in BeOS that I felt would have resulted in great amounts of pain and suffering 10 years later."

Rewriting things from the ground up, without acceptable justification, has never been an effective strategy.

Re:Question...

I disagree with the premise that there wasn't acceptable justification for rewriting things from the ground up. Remember that the key players at Be were Jean-Louis Gasse (sorry for the lack of grave or accent or whatever the French thing is...) and Steve Sakoman. Their primary prior experience was at Apple. The biggest mistake that they made was in trying to create a better Mac OS than Mac OS. What they ended up doing was creating something that looked more like a better UNIX than UNIX, except that it lacked all the things that made UNIX great in the first place. To start with, the biggest thing they left out of BeOS was multi-user capability. That, IMO, more than anything else was what led to the downfall of Be.

I lost a bit of change on Be stock. It still pisses me off, because Be had the nucleus of a great idea, but failed to follow through.

Re:Question...

This is good, I like this political stuff:

MS-DOS 1.0 was Herbert Hoover, aloof to the problems of the common man but friend of the engineer in all of us. Also discovered Transformers.

Mac OS 7-8-9, all Franklin Roosevelt, very competent, lead us through difficult times, but left a legacy of programs which have become quite a mixed bag.

Windows 3.1, Dwight Eisenhower, amiable enough, competent, but leaving historians (and many contemporaries) very wanting.

Windows 95 thru ME, Lyndon Johnson, one of the boys, very able at getting things done, but in the end a disaster, rightfully ceding his throne.

Windows NT, Richard Nixon, the archetypal back-room politician, ruthless, and ultimately brought down by little faults, but many believe he was a great president and did much to modernize the Republican Party.

Windows XP, Ronald Reagan, everybody who hates him never met him, he could charm anyone, the Great Communicator. Bought Iranian weapons for contras with drug money.

Mac OS X, Bill Clinton, cheerful and smart, if not the most productive. Known for his speeches.

Re:Question...

Vista, George W. Bush, elected because of his name, even though the prior iteration wasn't especially respected or well-liked. Introduced instability and performance issues, all in the name of "security". Many of the corporate interests who promoted him early on are having second thoughts.

Re:Question...

I think Windows 2000 would be Reagan for the reasons you pointed out. Windows XP would be George H. W. Bush for following in the footsteps of its predecessor while having a couple accomplishments of its own (Persian Gulf War). Vista would be George W. Bush--trying desperately to follow in the footsteps of its predecessors, security-obsessed, but overall a miserable failure with dire consequences for privacy and freedom.

Re:Question...

Linux, Fidel Castro, the communist leader that has been in office for ages, just refuses to resign or die and points nukes at Windows from time to time.

Microsoft's plan is to keep adding cores...

Microsoft's plan is for us to keep adding CPU cores in the hope that at least one of them won't be deadlocked at any given moment in time.

Multithreaded won't be optional any more.

Given that most machines are already starting to come default with 2 cores, and you can fit 8 cores (2 CPUs) in a nice desktop package, it's pretty clear that it's going to be a requirement.

It's not entirely the operating system's fault. The biggest advance of BeOS wasn't necessarily just that the kernel was designed to multithread nicely, Be also did their best to force you to write multithreaded code when you wrote a Be application.

I suspect that the first thing that's going to become clearly a performance bottleneck is the applications. And that's not going to be fun, because there's a lot of applications out there and you can't just magically recompile them with threads turned on and see much difference. You need to synchronize the data structures for multiple threads touching them at the same time and split things up so that you can actually keep a decent number of cores busy. This is not trivial when you are talking about an app that somebody wrote single threaded in the mid 90s without any notion that threads might be useful later.

Re:Multithreaded won't be optional any more.

Multithreaded CPUs are become more and more common, yes, look at Sun's Niagra with 8 cores & 4 threads per core (looks like 32 CPUs from the OS...). In the consumer desktop space, Intel/AMD both have 4-core CPUs either in the market or coming soon.

As for applications - if you're running 5 applications, multi-cores will help without recompiling assuming the kernel's scheduler is reasonably sane and kernel writers are getting smarter at writing different schedulers. If you are running one single-threaded app, multiple cores aren't going to help you much at all. Of course, the other advantage of multi-threading apps (even on a single core) is that if the app is blocking on one thing (I/O is most common for blocking), the other threads can carry on doing work.

Re:Multithreaded won't be optional any more.

Sure, but most desktops don't run more than one or two apps at a time. So, 2-4 cores is all that you get "for free" without new apps. Sure, if I'm building a web server application, it'll scale much more gracefully, but it already scales rather gracefully.

Are you serious? The idea is to have all your programs running all the time, and interact with them whenever you want with instantaneous response. Not to mention that most apps people run nowadays either are servers (P2P, LAN Shares, etc), clients that sit around listening to servers (IM) or querying them with frequent regularity (Email Client). And the progression is towards having personal servers that you can connect to using either a local or remote client.

The next generation of computing is going to come from the vast multitude of developers who are accustomed to writing client-server applications applying what they know to computers that behave like a server cluster. They are better equipped to approach the problems and rewards of this architectural progression than the guy who has been working in the traditional application space. Now, that's a generalization that's full of exceptions, but it'll be still be proven true on the wider scale.

Re:Multithreaded won't be optional any more.

Are you serious? The idea is to have all your programs running all the time, and interact with them whenever you want with instantaneous response. Not to mention that most apps people run nowadays either are servers (P2P, LAN Shares, etc), clients that sit around listening to servers (IM) or querying them with frequent regularity (Email Client). And the progression is towards having personal servers that you can connect to using either a local or remote client.

Are YOU serious? Not one of those applications/services you mention requires much CPU. A single CPU with a good scheduler can easily handle all of that with good responsiveness and little or no loss in overall performance. Well, in the case of Windows XP, it woudl also help to have a sane virtual memory system. A lot of the responsiveness problems you see on Win XP machines (Vista may have addressed this) is because Windows likes to swap apps out to disk when you minimize them. It has very little to do with available CPU power.

-matthew

Re:Multithreaded won't be optional any more.

Look at Windows. You realistically have somewhere in the area of 5-10 programs running simultaneously. Most of those programs take very little CPU and memory but in certain cases you will notice it. For example, the entire audio stack is service, so is UPnP, wired networking, wireless network discovery, indexing, etc.. Those things run most of the time and don't take a huge amount of resources but they do some which can lead to situations where they'll decrease system responsiveness. This isn't a standard Slashdot criticism of Windows, just an acknowledgement of the fact that usually LOTS of things are running when it seems like none are.

As an aside, I would think that a true micro-kernel based OS would work the best using multi-core. Putting every possible function in a different process would seem to be a better use of a multi-core architecture than to have larger kernels.

Re:No Maybe Yes

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:No Maybe Yes

This is a multithreaded comment, right?

I hope so

I still hate that BeOS went belly up. It was a great operating system but was crushed before it ever got very far. The hardware support was also amazing: it would run winmodems and other windows only hardware. I've never tried writing an operating system, but I hope some of the features from BeOS make it into linux/OSX. One interesting thing to note is Be was originally a mac alternative and was only later moved to x86.

Another cool operating system to check out is MenuetOS [menuetos.net]... it is written entirely in Assembly! Very fast boot times and the GUI and eevrything fits easily on a floppy!

Threading isn't any easier when it is pervasive

It isn't really the pervasive multithreading that does the job on responsiveness for BeOS, and nor does having the "two threads per window" thing (which I think is what the poster is referring to in terms of "pervasive multithreading) avoid "programmer's tricks" - in fact, you have to be just as careful as if you were developing with Windows, and span up a background thread. One issue for BeOS developers was the amount of hard thinking you had to do to perform simple tasks in a pervasively multi-threaded environment, when you're still having to deal with all the pitfalls of lock-based programming.

However, taking only a few cycles to spin up or kill a thread (rather than the 10,000 plus it takes Windows), or perform a context switch, is a significant help. (There used to be an interesting article benchmarking those things on the Be website, but I can't find it any more).

MS have also added some more interesting stuff to the scheduler in Vista, which helps with uninterrupted sound or movie playback, so at least some of that stuff is possible without a complete redesign.

BeOS rocked!

A few years ago, on a Dual Celeron 366Mhz with 256MB of RAM, I went out of my way to attempt to crash it. I opened about 120 OpenGL demos with only minor decrease in performance. After inherriting that mainboard, processors and RAM from my uncle and then increasing it to 512MB, the same test ground both FreeBSD and Linux to a halt.

Re:We had different programmers 10 years ago

Bah. Today's programmers aren't better or worse than they were ten years ago - they're just distributed differently. Programming video games on a console is an exercise in (frustration) poor tools, worse documentation, highly constrained memory / CPU / IO / bus, multiple threads utilitizing multiple specialized processors, microcode, assembly, etc. Ditto for cell phones. Not so for business applications.

So yes, if you mean "developers of business applications aren't generally hardcore down to the metal programmers," then I'd agree with you. John Carmack and Michael Abrash would be bored out of their skulls working on UI issues for Quicken 2008. And, given their aesthetic sensibilities, they wouldn't necessarily be the best choices (just *try* to balance your checkbook).

But if you mean that great programmers are no longer among us, then I'd say that you should change jobs, because it's more likely that they're simply not around *you*.

Re:We had different programmers 10 years ago

Bah. Today's programmers aren't better or worse than they were ten years ago - they're just distributed differently.

I am not so sure. I remember my first C++ class in college, we didn't touch C++ for at least half the semester (well almost). We learned the basics of OOP and the rest of time was spent on learning how compilers compile code. We also learned a lot of assembly. Hell, in mainframe assembly class we wrote an entire assembler. Bonus points were given to people who used their own assembler to generate the code of the assignment.

While C++, assembly and C might no longer be "cool", it definitely teaches people how to write optimal code, how to debug efficiently, understand a wide variety of computing concepts.

The same college today is too busy teaching C# and Java. While those languages are nice and all, not teaching low level C, C++ and assembly IMO leads to sloppy coders, people who don't understand the byte code generated, people who don't mind wasting system resources because hey ... the garbage collector will take care of it.

I was nearly crucified when I suggested my boss to recode a piece of an application in C so it scales better than the current shitty VB COM version. He just looked through me and said: add another server! Lot of today's code is written by people who don't even understand how the code is getting executed.

Re:We had different programmers 10 years ago

"I was nearly crucified when I suggested my boss to recode a piece of an application in C so it scales better than the current shitty VB COM version. He just looked through me and said: add another server! Lot of today's code is written by people who don't even understand how the code is getting executed"

Was it more cost effective to have a programmer recode it in C (which includes the required maintenance) or use the less optimal but easier to maintain VB COM? I'm all for using C over C#, Java, and VB, but sometimes you need to look at the situation from a business standpoint.

Re:We had different programmers 10 years ago

I was nearly crucified when I suggested my boss to recode a piece of an application in C so it scales better than the current shitty VB COM version.

His reaction likely had little to do with code and alot to do with business. To managment's ears you said "This part is done, but I want to take time and money and re-do it really shiny." Now if craftsmanship meant anything in terms of the sales of software, you may have been listened to. But since the hardware companies are all too quick to step up and offer a new gizmo that will have you computer running "blazing fast", the consumer thinks that the sluggish performance is a hardware problem. The end result of all of this is the management of software companies sees little to no reason to take any more time or money than necessary to make a program clean and efficient.

Better than xubuntu

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 [beosmax.org]

Beos is still a lot of fun on older hardware.

I don't get it

The ability to play eight movies simultaneously is a bad way of determining OS thread performance. Most modern operating systems have efficient, low-overhead threads. How well they play multiple videos depends much more on the display pipeline, the codec, and how the players adapt to load. To say anything about system performance, you'd need to know frame rate, resolution, codec, postprocessing options, etc.

Overall, I really don't see anything in BeOS that you don't get as well or better in a modern Linux system. BeOS has some efficiency gains from having been developed from the ground up with little need for backwards compatibility, but that's probably also why it wasn't successful in the market. And threading and scheduling in particular are highly efficient and mature in Linux.

(Not that OS X is basically a hacked NeXTStep; the NeXTStep kernel is Mach, the same kernel that is the basis of the GNU Hurd.)

Re:I don't get it

It's ok. Too bad there is no recursive directory support in inotify. Software has to add a watch for every subdirectory of a tree it wants to monitor.

So what? Why do you want to put more functionality into the kernel than necessary? You can write user-mode code around inotify for recursive watches--Beagle does just that. If enough people wanted it, it could be wrapped up as a library.

Haiku

Is not haiku(beos) open source?
Take the features and port to linux.
New scheduler rules them all.
Speed improvements would increase the desktop performance.
As they would increase performance with services.

Re:Uh, IRIX anyone?

Yeah, but yesterday's supercomputers are todays commodity machines. The last IRIX "super"-computer I used had 16 processors with a uniform memory architecture. We're quickly approaching that level on commodity hardware. My el-cheapo box has 2 processors with a uniform cache-coherent memory architecture.

What I'm getting at here is that perhaps we could look to the past for some ideas about multi-threading, and IRIX is not a bad choice at all, particularly since it was Unix-derived, like the Linux we use now, whereas BeOS is not.

Tried (for Windows) and killed

Recall that this was the effet of Intel's NSP (the ill-named "Native Signal Processing"), a real-time multui-thread scheduler inserted at the device-driver level of Windows. Combined with something called VDI (Video Direct Interface), which allowed applications to bypass the Microsoft GDI graphics layer in certain ways, this allowed multiple video, graphics, and audio streams, mixed and synchronized, on circa-1993 computers, something largely not even possible today. While NSP was intended primarily for media streams, its technology was broadly applicable to more responsive and vivid interfaces. The result was Microsoft's threat to cut off Intel from future Windows development and specifically to withhold 64-bit support from Itanium, to more publically support AMD (which they did, for a while), and to threaten any OEMs using the code with withdrawal of Microsoft software support. Much of this was detailed in the Microsoft anti-trust trial and the accompanying discovery documents. Under this pressure, Intel abandoned the software, transferring VDI to Microsoft (it formed the core of what was later called DirectX), and outright killing NSP. Andy Grove admitted to Fortune magazine "We caved." (http://cyber.law.harvard.edu/msdoj/transcript/sum maries2.html) This is not to suggest that this was the best or only way to do this, or that others haven't done it and done it well. But despite the best efforts of Linus and friends, Windows remains the dominant desktop OS, and Windows continues to be built on a base of 1970s-era operating system principles. Microsoft has, and continues to, build substantial barriers to anyone trying to substantially modify the behaviour of Windows at the HAL/device layer. Whether VMWare and equivalent virtualization technologies are finally a camel's nose under the tent edge remains to be seen. But as long as Windows remains the dominant desktop OS, you can expect the desktop to lag 10-15 years (at best) behind the state of the art in OS, GUI, and real-time developments.

Re:Tried (for Windows) and killed

Windows continues to be built on a base of 1970s-era operating system principles.

Thank Gawd Linux isn't using any relic of an OS [wikipedia.org] that started in the 1970's as its base! No, no, all 100% 21st clean legacy-free implementation there.

On a more serious note, I used Beos myself back in the day. It was definitely more responsive than Win98 was, but not everything was perfect either. The networking implementation absolutely sucked. Oh, it had lots of threads, its just that the threads were not all that beneficial to actual performance. The networking stack and some other forms of processing in the system that handle streams of many relatively similar tasks would probably parallelize better via a pipeline scheme where parallelism is achieved by having independent stages of the pipeline run in parallel (much as CPUs break up the task of executing instructions into a pipeline). The type of parallelism that works best can depend on the application, and the one-size fits all philosophy is not usually correct no matter what the solution is.

Yes

I'm a CS grad student at the University of North Carolina. I've never used BeOS, but I'm confident that responsiveness will increase, because the work I'm doing right now is attended to address this very issue.

The thing that makes multi threaded programming so difficult is concurrency control - it's extremely easy for programmers to screw up lock-based methods, deadlocking the entire system. The are newer methods of concurrency control that have been proposed, and the most promising method (in my opinion) is 'Software Transactional Memory' which makes it almost trivial to convert correct sequential code to code that is thread-safe. Currently, there are several 'High Performance Computing Languages' in development, and to my knowledge, they all include transactional memory.

The incredible difficulties involved in making chips faster are precipitating a shift to multicore machines. The widespread prevalence of these machines, coupled with newer concurrency control techniques will undoubtedly lead to an increase of responsiveness.

Re:Yes...well, maybe eventually...

Unfortunately, STM is very resource heavy and very slow. Yes, it abstracts away lots of issues, but that abstraction comes at a significant cost. In most instances, STM is slower than "classic" locking schemes until 10+ cores are available. (FYI: University of Rochester [rochester.edu] has a nice bibliography for STM info)

If/when the CPU designers currently screaming "more threads, more threads!" at us coders get around to implementing efficient h/w transactional memory, painless fine grain parallelism may become a reality. Until then, STM may be fine for very large applications on systems with huge memories and lots of cores, but probably isn't an option for the average desktop.

But STM does present some intriguing possibilities for distributed parallel environments (think STM + DSM).

Re:Yes...well, maybe eventually...

I think you misunderstand the ways in which STM are relevant to this sort of issue. Sure you can do full blown STM with crazy commits and rollbacks that are large and complex but that isn't what causes the problems with most threading issues. Really the primary benefit of STM is just to give an understandable and intuitive means to manage simple things that programmers now do with locks, e.g., making sure the other thread doesn't update part of the object while your thread is making some small change to it.

As far as performance the key here is compiler design. Sure in the fully general case STM may be fairly resource intensive but most cases aren't the general case. The hope is that compilers can be improved to natively support STM and recognize where simplifying assumptions can be made.

In other words practical STM is a way to get the compiler to meet the programmer halfway. Compilers can't do auto-parrililization and won't be able to anytime in the foreseeable future but having programmers deal with very low level constructs like locks and semaphores is confusing and a waste of time. This is a nice comprimise to meet in the middle. At least as long as it is used correctly.

Proof MS set computer industry back

I think both NeXTStep and BeOS are living (dead) proof that Microsoft set the computer industry back over a decade. 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. (The only downside to the NeXT: Netware networking sucked. But Netware networking sucked on everything but DOS, so I guess it's no surprise.)

Same with BeOS. It had many features, including stability, ease-of-use, and responsiveness that MS-Windows can't seem to find today. Granted, neither can GNU/Linux or Mac OSX, but since they are hardly the predominant OS, I can't really fault them to the same extent.

Anyway, it's an old rant. Never mind the ravings of an oldster who never got over the sopranoing Microsoft gave DR-DOS. Those like me are just bitter our careers turned from fun and interesting to tedious and dull because of Microsoft. Y'all go on and play with your shiny new toys. No, really, don't mind me. I'm just gonna sit up here on my porch and get rip-roaring drunk and talk about the old days, whether anybody's listening or not.

Multithreaded Windows

[BSOD]

  . , . . , . . [BSOD]

  - . [BS0D]

[BSOD]

  . . , . [BS0D]

  - . [BSOD]

Ummm...

The big advantage with threads is that the TLB doesn't have to be flushed on a context switch, since they share the same address space. This has great performance advantages over processes, but you lose all of the advantages of protected virtual memory, hence the need for locks, mutexes, critical sections, etc. Threads are actually a step backward from a reliability/security standpoint.

BeOS was a single-user system, if I recall, so that partially reduces the need for the security features that having multiple processes provide.

But beyond that, modern OS's seem to offer a lot more flexibility. They have processes if you want separation of address space, shared memory if you need better performance for communication between threads, threading if you want a shared address space, and user-level threading libraries for the ultimate in performance if you're willing to spend the time to code it properly.

Being able to watch eight movies at a time is a neat trick, but it's not particularly useful, especially when we'll soon have processors with a ridiculous amount of cores on them. With a large number of cores, the overhead of a process context switch is hardly more than that of a thread, since a CPU intensive process can run on its own core.

I think the future of OS's is more likely to be in micro-kernel architectures that can move processes around efficiently to balance the processing load between many CPUs. Or a hybrid microkernel/monolithic architecture that could run the big kernel on one CPU for tasks that require responsiveness, and the rest of the kernel processes balanced between remaining CPU's for throughput.

Is High Performance Computing Really the Goal?

Ask yourself this question, "Is High Performance Computing Really the Goal?" or is herding the consumer to newer shinier hardware the goal? The amount of computing power found in a typical Pentium III computer sitting out and someones curb far exceeds the needs of most users.

Re:Is High Performance Computing Really the Goal?

I'm so sick of hearing that most users don't need anything greater than say a P3. That is bogus. Users today do more things with their computers than was done during P3's day. Today, people retouch photos and import them into a library with thousands of photos, they render home movies taken from their camcorder, they run movies (quicktime, flash, etc.) at hi resolutions and at full screen, they rip CDs, they sometimes rip DVDs, video teleconferencing, and so much more. Heck, you need a decent system to render most popular websites today. Here's my generalization: Most slashdotters don't give "Joe Six-Pack" enough credit. He may not know how it works, but he uses more features than you think. The fact is that the software has gotten easier and more powerful, thus allowing people to use more and more features. To say that most users don't need anything more than 6 year old technology is insulting to software developers. It essentially is saying that these developers have been wasting their time for the past 6 years.

Change programming language instead of OS

Programming languages like Haskell and Erlang has very little problems with using a massive amounts of CPUs/cores. Look them up and learn about them, and you'll see that they can, without any fuss, spread over many many threads without any special code at all.

Well, that's it, read up and then maybe we can get some more interesting Slashdot postings about new computers:)

And it is quite amazing that Sun hasn't picked up on this. Their little Java thingie doesn't scale that well after all:)

Re:BeOS was awesome

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.

Huh. BeOS fast?

Let me know how long it takes to start OpenOffice on BeOS.

Rose-tinted hindsight...

Back when BeOS was still cool, and Rhapsody was hot, and NT was still counting by numbers instead of names, I installed BeOS, Rhapsody DR1, and NT 4 on the same hardware... a Pentium with 16MB of RAM... not exactly state of the art but not ridiculous for the time either.

BeOS showed no exceptional capabilities. Both Rhapsody and NT were easily able to run multiple concurrent applications without slowdown, and BeOS was at least as often bottlenecked on I/O.

BeOS was certainly a competent OS design, but the "remarkable" performance was only remarkable when it was compared with the classic Mac OS and mainstream Windows 9x. With those as the "competition", the legend of BeOS has grown over the years, but any contemporary preemptive multitasking OS could do as well.

Threads are not magic

There is nothing magic about threads. Sometimes a multi-threaded process is the right approach, sometimes a multi-PROCESS application is better. Sometimes a process is intrinsically serial in nature and any gain from threading will be more than swamped by the overhead.

While sometimes obscured by terminology, threading isn't a single entity. For example, if a process mmaps in blocks of memory with MAP_SHARED, then creates pipe pairs and forks, it IS a multi-threaded application in some sense, but isn't what many think of as threaded. For that matter, the mmap step can be skipped for some server applications and still be multi-threaded.

A single process with a single thread in it MIGHT be somewhat multi-threaded if it does it's I/O through various asynchronous calls.

At the same time, an application that explicitly calls thread creation functions might be effectively single threaded if resource (lock) contention is such that no more than one ever runs at the same time. Another case of being effectively single threaded is when an application is event driven and even though events are dispatched to worker threads, the thread typically completes it's handling before the next event comes in. This will often be true of interactive applications where the user won't likely keep issuing commands until they see the results of the previous command.

OTOH, things like image processing in GIMP could stand to be multi-threaded where the work is tiled and dispatched to worker threads.

Until recntly, multi-threading has only been beneficial to a small percentage of users anyway. Most people until recently have had single processor systems.

BeOS's legendary media handling was more the result of carefully designed and tuned media subsystems than pervasive threading.