Log in

No account? Create an account
Adventures in Engineering
The wanderings of a modern ronin.

Ben Cantrick
  Date: 2006-09-01 00:55
  Subject:   [Digg] The Problem With Threads

From a fundamental perspective, threads are seriously flawed as a computation model because they are wildly nondeterministic, as the "Nondeterminism and Threads" sidebar describes. The programmer's job is to prune away that nondeterminism. We have developed tools to assist in the pruning: Semaphores, monitors, and more modern overlays on threads offer the programmer ever more effective pruning. But pruning a wild mass of brambles rarely yields a satisfactory hedge.

We must and can build concurrent computation models that are far more deterministic, and we must judiciously and carefully introduce nondeterminism where needed. Nondeterminism should be explicitly added to programs, and only where needed, as it is in sequential programming. Threads take the opposite approach. They make programs absurdly nondeterministic and rely on programming style to constrain that nondeterminism to achieve deterministic aims.

Post A Comment | 2 Comments | | Link

Alex Belits
  User: abelits
  Date: 2006-09-01 05:05 (UTC)
  Subject:   Reason for all this: Windows IPC sucks ass.
Overuse of threads is a direct result of a flaw in Windows design that caused IPC to become nearly unusable for all imaginable purposes, so now we have a generation of programmers that see threads as the only possible mechanism of implementing concurrency in userspace programs.

Sure, data exchange between threads is in general faster than use of IPC mechanisms (though when the application uses asynchronous stream semantics, pipes are faster than locking chunks of a shared buffer), and large number of processes with separate data may run into VM inefficiencies faster than a bunch of threads, however in recent two decades we have seen a huge number of resource-wasting techniques with less practical benefit than IPC vs. threads, and all those things are considered good, practical and worth the price.

Yet thanks to Windows programmers aren't even aware that you can fork a bunch of processes and pass data between them asynchronously with either no or very lightweight serialization overhead, and have a completely lockless processing model -- all locks and VM/scheduler optimizations are in the kernel already.
Reply | Thread | Link

Ben Cantrick
  User: mackys
  Date: 2006-09-01 06:41 (UTC)
  Subject:   (no subject)
Amen to that. I still think built-in serialization is one of the two best features of Java.
Reply | Parent | Thread | Link

May 2015