If the problem is IO bound to a single, local, harddisk, and is uncacheable, then concurrency may not help.

Yes. I appreciated your detailed response.

(Fwiw, in my original comment I meant that a problem that is as you describe is really IO bound, and a problem that isn't, isn't.)

Only mathematicians and computer scientists demand total determinacy; and throw their arms up in refusal to work if they don't get it.

I think you've misinterpreted The Problem with Threads. The author was not demanding total determinacy (which I agree would be profoundly bogus). To quote from the abstract: "Nondeterminism should be explicitly and judiciously introduced where needed, rather than removed where not needed."

don't throw the baby out with the bath water. Flames are dangerous; but oh so very useful.

While your particular choice of metaphors has me imagining a complicated maneuver involving strong folk, an old fashioned bath, a gassy baby, a lighter, and some sort of worthwhile singeing operation, I don't think your point is that far adrift from (Perl) "should not hide the existence of OS-level threads, or fail to provide access to lower level concurrency control constructs".

Futures neither remove the complexity nor solve the problems; they just bury them under the covers forcing everyone to rely upon the efficacy of their implementation and the competence of the implementors.

I confess to being amazed by this statement. Are you really saying that, when solving any concurrent problem correctly (data-wise), Futures are never (or seldom) simpler for the programmers writing, reading, and modifying the code than directly using the underlying low level concurrency constructs (which I'll hand wavily define as threads, locks, cas, etc.)?

Do you think there are any very useful high level concurrency constructs?

The "heaviness" of P5 threading is a misnomer. The threads aren't heavy; the implementation of shared memory is heavy. And that could easily be fixed. ... They've basically stagnated for the past 8 or more years because p5p won't allow change.

I'd appreciate a link to a decent recent technical discussion of the problem of the heaviness of shared memory in P5 and reasonable potential fixes. Failing that, a couple paragraphs that summarize the problem and the fix you're suggesting would be great. Or maybe you could write a meditation that invites monks to focus on the technical issues related to the problem and potential fixes?