global interpreter lock

[phil hunt]

On 26 Aug 2005 14:35:03 -0700, Paul Rubin <http://phr.cx@NOSPAM.invalid> wrote:
>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.

It's not the number of paths that's important.

What's important is *predictability*, e.g. which instruction will
the computer execute next?

If you only have one thread, you can tell by looking at the code 
what gets executed next. It's very simple.

If you have 2 threads you can easily have a timing-based situation
that occurs rarely but which causes your program to behave wierdly.
This sort of bug is very hard to reproduce and therefore to fix.

>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. 

Yes, and introducing code that makes randomly-occurring bugs more
likely makes debugging inherently harder.

> That means facing the problem and finding
>solutions, not running away.

Yes, find solutions. Don't find dangerous dead-ends that look like 
solutions but which will give you lots of trouble.

-- 
Email: zen19725 at zen dot co dot uk