multiprocessing.sharedctypes and built-in locks

[Ahmad Syukri b]

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

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)
if b.acquire():
 b[0] += 1
 b.release()

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)