[Bryan Olson] >>I don't see much point in trying to convince programmers that >>they don't really want concurrent threads. They really do. Some >>don't know how to use them, but that's largely because they >>haven't had them. I doubt a language for thread-phobes has much >>of a future.
[Mike Meyer] > The real problem is that the concurrency models available in currently > popular languages are still at the "goto" stage of language > development. Better models exist, have existed for decades, and are > available in a variety of languages. I think that having a concurrency mechanism that doesn't use goto will require a fundamental redesign of the underlying execution hardware, i.e. the CPU. All modern CPUs allow flow control through the use of machine-code/assembly instructions which branch, either conditionally or unconditionally, to either a relative or absolute memory address, i.e. a GOTO. Modern languages wrap this goto nicely using constructs such as generators, coroutines or continuations, which allow preservation and restoration of the execution context, e.g. through closures, evaluation stacks, etc. But underneath the hood, they're just gotos. And I have no problem with that. To really have parallel execution with clean modularity requires a hardware redesign at the CPU level, where code units, executing in parallel, are fed a series of data/work-units. When they finish processing an individual unit, it gets passed (physically, at a hardware level) to another code unit, executing in parallel on another execution unit/CPU. To achieve multi-stage processing of data would require breaking up the processing into a pipeline of modular operations, which communicate through dedicated hardware channels. I don't think I've described it very clearly above, but you can read a good high-level overview of a likely model from the 1980's, the Transputer, here http://en.wikipedia.org/wiki/Transputer Transputers never took off, for a variety of technical and commercial reasons, even though there was full high-level programming language support in the form of Occam: I think it was just too brain-bending for most programmers at the time. (I personally *almost* took on the task of developing a debugger for transputer arrays for my undergrad thesis in 1988, but when I realised the complexity of the problem, I picked a hypertext project instead ;-) http://en.wikipedia.org/wiki/Occam_programming_language IMHO, python generators (which BTW are implemented with a JVM goto instruction in jython 2.2) are a nice programming model that fits neatly with this hardware model. Although not today. -- alan kennedy ------------------------------------------------------ email alan: http://xhaus.com/contact/alan -- http://mail.python.org/mailman/listinfo/python-list