Python threading and sharing variables

[Chris Angelico]

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.

ChrisA