I'm also unsatisfied.
I have done a fair bit of concurrent programming. I've become
reasonably facile with locks and so forth, and can write complex
multithreaded Java programs without deadlock or race conditions.
(Mostly.) But I'm not happy with it. Even if *I* can do it, it is
often the case that other people on my team can't. I think even
the built-in support for concurrency in Java is too low-level.
As has been said before numerous times, shared state concurrency
is the wrong default.
I want a better model.
And by better, it has to include not only better handling of
issues such as deadlock. It also has to be *simpler.* The
simpler it is, the more people it will be accessible to.
Now on occasion I get to discuss some of these issue with
the Great Minds of the Java universe. While aware of the
problem, I don't think they appreciate sufficiently the necessity
of a radical solution. Their current thinking is in the direction
of lock-free data structures. However these strike me as
being still too low-level. I still have to design some application
protocol to make appropriate use of these lock-free collections.
It seems to me the problem necessitates being able to *read*
shared state and modify shared state based on the read.
Just being able to do a lock-free insert into a collection isn't
going to get you that.
I have had in mind for a while now the idea of comparing and
contrasting various approaches to the problem. I am thinking
specifically of starting with Dining Philosophers; it is a well
known problem that manages to have some meat to it while
still being quite simple. My first thought was to compare a
Java-native concurrent implementation of Dijkstra's algorithm
with one using SQL via JDBC. I see now that I have to
consider the locking properties of the dbms in question, sigh.
And I suppose I should also try to use the lock-free data
structures new to java.util.concurrent.
We don't talk much about concurrency in the RM. I guess it
feels like an implementation issue, but maybe it isn't, at least
if we want to think about concurrent programs. TTM is silent
on the issues of concurrency. I note the existence of various
process calculi, such as the pi calculus and the flow calculus;
somehow they are not appealing.
More discussion, please.