Author sbt
Recipients lechten, sbt
Date 2013-01-20.10:57:25
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1358679448.22.0.329808637303.issue16998@psf.upfronthosting.co.za>
In-reply-to
Content
> 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.)
History
Date User Action Args
2013-01-20 10:57:28sbtsetrecipients: + sbt, lechten
2013-01-20 10:57:28sbtsetmessageid: <1358679448.22.0.329808637303.issue16998@psf.upfronthosting.co.za>
2013-01-20 10:57:28sbtlinkissue16998 messages
2013-01-20 10:57:25sbtcreate