[brackett]

Originally Posted by amac

I don't think it is confusing the issue at all. Firstly processes are always 'owned' by the OS. They are as high level as an application can get. Threads are a part of processes, but multi-threading often refers to what might better be described as multi-processing.

According to Wikipedia, multi-processing refers to using multiple CPUs to execute simultaneously - which is where this discussion started. Without multiple CPUs (or cores), you're really just switching tasks on a single CPU.

The discussion is, I think, when and whether multi-threading is advantageous. My argument is that it's actually *not* that much of an advantage now (because you're not "multi-processing", since 95+% of desktops are single core) but that it will become increasingly important as dual and quad cores become common place. Also, there's both a (slight) performance penalty, and a increased maintenance cost with multithreaded code. All of that needs to be considered.

Originally Posted by amac

Context switching doesn't take place on user-level threads (what we've been calling 'threads' so far).

Hmmm...how does the processor save and load the stack (among other things) to execute a new thread then? I assume you're "user-level threads" are what I term fibers? Cooperatively scheduled threads, with scheduling handled in userspace (as opposed to preemptively scheduled threads, with scheduling handled in the kernel)? While it's true that a context switch between processes is heavier than a kernel thread, and a switch between kernel threads is heavier than a user thread, to say there's no context switch penalty is off the mark.

Originally Posted by amac

The point is that kernel level threads (processes) have to perform context switches and lock on shared data, but user-level threads don't. They exist for this reason - efficiency!.

Kernel level threads are not processes - they are the normal multi-threading model in the languages and systems I am familiar with. AFIAK, Windows, Linux, .NET, Java, and even Solaris all use kernel level threads. (To be fair, earlier implementations of Solaris, and the JVM used fibers, but their current implementations do not. Also, Windows NT has a fiber API to compete with earlier Solaris versions, but it's use is strongly discouraged. I *think* that Ruby uses fibers, or some sort of hybrid model).

If there is no need for locking on shared data, somebody should tell the Java folks that the synchronized keyword is no longer needed.

Originally Posted by amac

Writing a multi-threaded program where user input is required (as well as processing) is much, much simpler than writing a single-threaded one. Java abstracts from any complexity, and doesn't resort to mindless polling etc. How would you go about breaking "long running process in manageable chunks and poll the input in between chunks" whilst still getting all user input? It would be insane. It's not multi-threading thats inefficient - polling is.

In the example given, you're actually right. Since you're talking about getting input from a keyboard, you're able to set it up with an IRQ handler. I ran with the example given, and botched it - mea culpa. My point, however, that multi-threading is *not* (generally) faster on a single CPU system remains.

Originally Posted by amac

He doesn't. He really doesn't.

While I have no problem with you disagreeing with me, and even pointing out that I'm a blathering idiot - I'd prefer you do it within the context of the discussion.

I didn't make it a point to show that you confused "kernel-level threads" with processes, and stated that "processes" need to lock on shared data (they don't - processes communicate via IPC, and have no shared data) or that you imply that you don't need to lock on shared data within Java (a dangerous point of view, BTW). Instead, I simply replied to your arguments. I'd appreciate it if you kept the same civility.