[brackett]

Originally Posted by amac

When you say that multi-threading is not faster on a single CPU. Not faster than what?

If you're writing a network server, you have a couple of ways of handling multiple requests. You can implement 1 thread per connection with blocking sockets (or, in *NIX, you'd normally do a fork and have 1 process per connection), or you can have an array of non blocking sockets and use a single thread to select() from them. If you use the select() method, you can then either handle the client inline, start a new worker thread to handle the client, or use a threadpool to service the client.

Traditionally, select() (combined with inline handling, or a threadpool - mainly depending on how long you'd be talking to the client) would be the most performant and scalable (actually, I/O completion ports would be better under Win32, but only because select() is poorly implemented). At a couple of hundred connections, having a single thread per connection will result in your app spending most of its time in thread management (starting, stopping, or switching).

But, back to my original point. multicore CPUs start to tip the balance back towards multithreading, as you can now utilize both cores (the Apache model of using multiple processes, each handling a set of sockets with a select() call, would also work - but is probably more complicated to design).

Originally Posted by amac

I couldn't give you an example of a program that uses multiple threads that could be better written in a single thread; because as I said before, you resort to polling or you start rejecting input.

And what do you think your second thread has to do (excepting an IRQ handler, as we discussed before)? Having a second thread waiting on something doesn't remove polling or blocking, it just switches it to another thread. As a bonus, the CPU now has to wake up that other thread every once in a while to see if it's ready to do something.

The basic fact is that a single core CPU can only run a single thread at a time (excepting HyperThreading, which comes with its own set of rules). There's no way you can get around that. So, in effect, you're just splitting out half your logic, forcing the CPU to switch between the 2, and have to worry about shared data, locking, and synchronization (whether or not that's a big deal depends on your design and app, of course).

Originally Posted by amac

Imagine writing a web-browser in a single thread. Aside from the size of the code-base, how would you handle connections to multiple web-pages without polling?

Non blocking sockets. And I don't see how it would increase the size of the code base at all - in fact, since you don't have to deal with locking and synchronization, it'd probably be smaller.

I'm not familiar with the internals of any web browser, but I suppose you could dig up any browser written for DOS or Win 3.1 and see a single threaded browser in action.

Note that I *wouldn't* necessarily design it that way. I think that a web browser design would probably lend itself nicely to a mutlithreaded design; I actually use multiple threads quite a bit - but I am aware of the limitations and alternatives.

Originally Posted by amac

My point is, that in single core processors, threads allow programs to abstract away the difficulty of scheduling multiple jobs.

And abstraction is a fine goal - but, as in most things abstracted, you lose out on performance. In multithreaded, you also (usually) lose out on maintenance.

Originally Posted by amac

It's slower where it isn't needed. But in programs that require multiple connections (or similar) it isn't possible to do it more efficient any other way.

It's never *needed*. Witness all of the single threaded apps produced for DOS, Win 3.1, and (most) embedded systems (all of which do not support multithreading).

It's a design choice. And, like all design choices, it's gotta be made in context. My original point was that multicore CPUs change the balance, and multithreading will likely become more common and the correct choice more often.

Unfortunately, a lot of programmers do not understand the difficulties in multithreading, locking, and synchronization. Mainly because they run on a single core CPU which (since it really only runs 1 thread at a time) masks a lot of the bugs in their code. Move that to a multicore CPU, and all of those data corruption issues, deadlocking, etc. will happen a lot more often.