global interpreter lock

[Mike Meyer]

Paul Rubin <http://phr.cx@NOSPAM.invalid> writes:

> zen19725 at zen.co.uk (phil hunt) writes:
>> >Let's see. Reality is that writing correct programs is hard. Writing
>> >correct programs that use concurrency is even harder, because of the
>> >exponential explosion of the order that operations can happen
>> >in. Personally, I'm willing to use anything I can find that makes
>> >those tasks easier.
>> Indeed so. Use threading (or whatever) when one has to, use an 
>> asynchronous single-threaded process whenever you can.
> This is silly.  You could say the exact same thing about if
> statements.  The number of paths through the program is exponential in
> the number of if statements executed.  So we better get rid of if
> statements.

The number of paths through a program isn't exponential in the number
of if statements, it's multiplicative. Each if statement multiplies
the number of paths through the program by 2, no matter how many other
statements you have.

On the other hand, with threads, the number of possible execution
orders is the number of threads raised to the power of the number of
instructions (assuming that instructions are atomic, which is probably
false) in the shared code segment. It's a *much* nastier problem.

> Really, the essence of programming is to find ways of organizing the
> program to stay reliable and maintainable in the face of that
> combinatorial explosion.  That means facing the problem and finding
> solutions, not running away.  The principle is no different for
> threads than it is for if statements.

Correct. But choosing to use a tool that has a less complex model but
solves the problem is *not* running away. If it were, you'd have to
call using if statements rather than a goto running away, because
that's that's exactly what you're doing.

I do agree that we should face the problems and look for solutions,
because some problems can't be solved with async I/O. That's why I
posted the article titled "Static vs. dynamic checking for support of
concurrent programming" - I'm trying to find out if one potential
solution could be adapted for Python.

       <mike
-- 
Mike Meyer <mwm at mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.