The Marquee de Sells writes...
We'll have to have much better language-level support for concurrent programming. What we have now sucks.And concurrently, Tim Bray writes...
Almost by definition, the slow media-centric apps should be able to deploy parallelism to good effect. But this deployment work is not for the faint of heart, because thread-aware programming is, well, hard...Agreed then. We need better languages and runtimes (example1, example2), better tools (example1, example2, example3), and better patterns (example1, example2, example3).If we’re going to empower application programmers to get the most out of the high-TLP chips, we need big advances in development and debugging technology...
Once we figure out some design patterns, there are grounds for hope that we can do some tooling around it.
1 comment:
I wanted to post this to Tim Bray but his blog didn't allow posts. I've worked with a group here at Carnegie Mellon called the Fluid project. They have developed the ability to statically assure that your concurrency model matches your code. The tools also make it trivial for you to indicate your concurrency model by guiding you in adding minimal annotations in the code (think javadoc). The fluid web site is at:
http://www.fluid.cs.cmu.edu:8080/Fluid
The publications (including Aaron Greenhouse's PhD thesis) are at:
http://www.fluid.cs.cmu.edu:8080/Fluid/fluid-publications
I post it here as a guide to how this might be done in dynamic languages but also to help Tim out with his java concurrency issues. Could someone see that it gets to Tim?
Larry Maccherone
LMaccherone ..at.. cmu ..dot.. edu
Post a Comment