Message180286
> I see. Then this is a documentation bug. The examples in the
> documentation use such non-thread-safe assignments (combined with the
> statement "These shared objects will be process and thread safe.").
Are you talking about this documentation:
If lock is True (the default) then a new lock object is created to
synchronize access to the value. If lock is a Lock or RLock object then
that will be used to synchronize access to the value. If lock is False
then access to the returned object will not be automatically protected
by a lock, so it will not necessarily be “process-safe”.
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.
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.) |
|
Date |
User |
Action |
Args |
2013-01-20 10:57:28 | sbt | set | recipients:
+ sbt, lechten |
2013-01-20 10:57:28 | sbt | set | messageid: <1358679448.22.0.329808637303.issue16998@psf.upfronthosting.co.za> |
2013-01-20 10:57:28 | sbt | link | issue16998 messages |
2013-01-20 10:57:25 | sbt | create | |
|