I disagree with this characterization of deadlock. The Wikipedia article [1] defines it as: “A deadlock is a situation where in two or more competing actions are each waiting for the other to finish, and thus neither ever does.” This is exactly what is occurring in the dining philosophers code I gave, which is why the post describes it as deadlock.

The event loop remaining responsive is not an accomplishment — operating systems remain responsive when some of their threads deadlock as well.

[1] http://en.wikipedia.org/wiki/Deadlock

http://www.erights.org/talks/thesis/

I talk about the performance on a quad-core in the post.

Right, if you want to do things in sequence, do them in sequence. But if you have a critical section that lasts through more than one event-loop turn, you need to use a lock, or some other synchronization construct.

I do think, however, that it’s worth pointing out that the semantics of setting two timeouts to fire within a short period of time* is “Do these two things, I don’t care which one you do first.” If you care about the order of the two operations, use a setTimeout chain.

I know this was a contrived example meant to serve your larger point, but wanted to make sure that random google refugees don’t wind up walking away from this post with the impression that locks are the solution to setTimeout non-determinism.

* Where ‘short period of time’ means close to the minimum timeout the browser supports

Shared mutable state is one way to implement locking, and shared state manipulations often require synchronization, so may introduce deadlocks. Otherwise, I think the main effect of shared mutable state is to make it easy to observe non-determinism, as you noted in your first code example. Deterministic concurrency models are possible when we remove shared state mutation.

I think the LtU discussion on “The Problem with Threads” touches some of these points:
http://lambda-the-ultimate.org/node/1481

On the mandelbrot code from the shootout, now in the git repository here: https://github.com/plt/racket/blob/master/collects/tests/racket/benchmarks/shootout/mandelbrot-futures.rkt I get substantial speedups on 4 cores. What does your code say that’s it blocking on?

On the "image-processing" problems… I'm starting with 2htdp/image images, but rendering them to bitmaps before even trying to parallelize anything. Then I have one future working on (say) the top 25 pixel rows, another on the next 25 pixel rows, and so on. All the computations are completely independent; they are reported using bytes-set!, with no two futures affecting the same offset.

By image processing, do you mean images from the 2htdp/image library? If so, they’re almost certainly not going to parallelize well with futures. The sweet spot for futures currently is programs like the mandelbrot benchmark: almost no communication, and all parallel operations are very simply (numeric computation, vector manipulation, etc).

Also, have you looked at the messages the futures library gives about what it’s blocking on?