multiprocessing.sharedctypes and built-in locks
Ahmad Syukri b
syockit at gmail.com
Tue Mar 17 00:57:29 CET 2009
On Mar 16, 5:19 pm, Aaron Brady <castiro... at gmail.com> wrote:
> It's not one of the guarantees that Python
> makes. Operations aren't atomic by default, such as unless stated
Well, in the documentation for RawArray:
"Note that setting and getting an element is potentially non-atomic –
use Array() instead to make sure that access is automatically
synchronized using a lock."
So I assumed operations for Array() would be atomic
> > I also realized that the created lock's release and acquire
> > methods are also imbued to the created shared object, and this is also
> > undocumented.
> Sorry, I don't follow you.
Sorry if that wasn't clear. By this, I meant:
b = multiprocessing.Array('i',5)
b += 1
though you don't get to use the with statement with this one. Also
only one RLock is created per array, whilst my code needed a lock for
each array member.
> By the way, your first example didn't
> produce the expected result on my machine-- even with the 'if
> __name__' statement.
Strange, I just copied and pasted the first example on a new blank
file and ran python3 with it again, it comes out find and dandy
(totalling 400000). I also tried the second example with the gl.append
line deleted, and it also runs (of course, with the wrong results)
More information about the Python-list