Python threading and sharing variables

[eryk sun]

On Wed, Jul 5, 2017 at 5:06 PM, Chris Angelico <rosuav at gmail.com> wrote:
> On Thu, Jul 6, 2017 at 2:24 AM, eryk sun <eryksun at gmail.com> wrote:
>>> But what could it do? Most likely, it's going to end up mutating a
>>> dict (the core type), so unless the __setitem__ is itself maintaining
>>> complex state that needs a lock, all you've done is move the problem
>>> around, and the same solutions work.
>>
>> That was my point. A namespace mapping could override __setitem__ and
>> __getitem__ to implement a name as something like a computed property
>> that's based on multiple values. Then if __setitem__ gets interrupted
>> in the middle of updating this set of values, another thread that gets
>> the computed 'property' will see a bad state. The GIL doesn't help. It
>> would need locking to make accessing the 'property' work as an atomic
>> operation, just like the case with regular properties. Again, I have
>> never seen anything like this in practice.
>
> Sure it could. And if it does, it's *it's* responsibility to use locks
> - not the caller's. From the caller's point of view, it's still a
> single operation, and should remain so.

I feel it's necessary to emphasize that there's nothing inherent in
the CPython bytecode operations for storing and loading a name that
guarantees atomicity. The namespace has to provide the guarantee that
backs up a statement like "[y]ou can be confident that a single
assignment will happen atomically".