Jens Lechtenboerger added the comment:
> It only says that accesses are synchronized. The problem is that you were
> assuming that "+=" involves a single access -- but that is not how python
> works.
Yes, I understand that by now (actually since your first comment).
> Where in the examples is there "non-process-safe" access? (Note that waiting
> for the only process which modifies a value to terminate using join() will
> prevent races.)
In section "The multiprocessing.sharedctypes module" the assignments in the
first example (function modify()) are unsafe. None of them is protected by a
lock as suggested in your first comment. Strictly speaking, no lock is
necessary in the example as there are no race conditions (the processes work in
an alternating fashion without concurrency).
I certainly did not see that the example (for a *shared* memory data structure)
is based on the implicit assumption of a single writer. In contrast, I assumed
that some "magic" should offer process-safe usage of "+=", which made me file
this bug. That assumption has turned out to be wrong. To prevent others from
being mislead in the same way I suggest to either protect those operations with
locks (and comment on their effect) or to state the implicit assumption
explicitly.
Maybe add the following after "Below is an example where a number of ctypes
objects are modified by a child process:"
Note that assignments such n.value **= 2 are not executed atomically but
involve two operations, a load followed by a store. Each of these operations
is protected by the Value's lock, which is dropped in between. Thus, in
scenarios with concurrent modifying processes you may want to explicitly
acquire the Value's lock to ensure atomic execution (avoiding race conditions
and lost updates), e.g.:
with n.get_lock():
n.value **= 2
----------
_______________________________________
Python tracker <[email protected]>
<http://bugs.python.org/issue16998>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
