is +=1 thread safe

[Gary Herron]

Carl Banks wrote:
> On May 3, 7:44 pm, Gary Herron <gher... at islandtraining.com> wrote:
>   
>> Alexander Schmolck wrote:
>>     
>>> AlFire <spamgrinder.tryla... at ggmail.com> writes:
>>>       
>>>>> The threading module already has a function to return the number of Thread
>>>>> objects currently alive.
>>>>>           
>>>> I have threads within threads - so it does not suit me :-(.
>>>>         
>>> How about using a scalar numpy array? They are mutable, so I assume that x +=
>>> 1 should be atomic.
>>>       
>> No NO NO! The only way to increment a variable in memory is through a
>> three step process:
>>     
>
> Yes, this will be atomic.  It's a pretty good idea, in fact.  The
> underlying increment operation is protected by the GIL; it could be
> three, forty, or a hundred steps and it'd be atomic at the Python
> level.
>
>   

But... It's not!  

A simple test shows that.   I've attached a tiny test program that shows 
this extremely clearly.  Please run it and watch it fail.  In this test, 
two threads both increment a shared global variable 1 million times.  
This should end with a value of 2 million, but it rarely does so.   
(Actually it has *never* done so yet.)

The GIL makes sure no two Python threads are running at the same time,  
and from that you can conclude that Python virtual machine instructions 
are atomic, but you cannot conclude that Python statements/expression 
are atomic.  Any Python statement or expression that compiles into more 
than one OP code can be interrupted between those OP codes, and this can 
cause devastating results to the interrupted statement.

Gary Herron


> Carl Banks
> --
> http://mail.python.org/mailman/listinfo/python-list
>   

-------------- next part --------------
A non-text attachment was scrubbed...
Name: t.py
Type: application/python
Size: 487 bytes
Desc: not available
URL: <http://mail.python.org/pipermail/python-list/attachments/20080504/21a91bae/attachment-0001.bin>