Parallelization on muli-CPU hardware?

[Daniel Dittmar]

Jeff Shannon wrote:
>    a = b + c
>    d = b + c
>    assert (a == d)

I don't think that anybody expects the assertion to be true if threads 
and any global variables are involved.

 > I cannot guarantee that the assertion is true, unless I explicitly
 > lock all the variables involved -- four locking operations plus four
 > unlocking operations.

Trying to lock more than one object automatically is a recipe for 
deadlocks.

> causing a segfault -- again, a violation of one of Python's design 
> constraints.  And I don't think that it's practical to have the 
> interpreter infer where it'd be safe to release the GIL.

Unlike Java (1), Python assignments are not atomic operations, but 
rather complex operations (updating of a dictionary).

Dictionaries would be locked at the C-level, so every assignment to 
module or instance variables would trigger at least one lock.

I'm not sure if locals () would have to be locked. As Pythons closures 
can't assign new values to variables of the surrounding scope, I'm not 
aware of a situation where a local variable could be updated (2) by a 
second thread.

Although 'Garbage Collection' fits your 'MSL: (many small locks) would 
slow down the overall execution of Python programs.' in name, it is 
technical a very different solution from locking the reference counter, 
probably with very different performance implications.

Daniel

(1) assignments of certain types is not guaranteed to be atomic on Java
(2) 'updated' is here meant as assigning a new value, not as calling a 
method on a mutable object.