Carl Banks wrote:
On May 3, 7:44 pm, Gary Herron <[EMAIL PROTECTED]> wrote:Alexander Schmolck wrote:AlFire <[EMAIL PROTECTED]> 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
t.py
Description: application/python
-- http://mail.python.org/mailman/listinfo/python-list
