global interpreter lock

[Alan Kennedy]

[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