On Wed, Jul 5, 2017 at 11:50 PM, eryk sun <eryk...@gmail.com> wrote:
> Assignment of a single variable in an unoptimized namespace isn't
> completely immune to this -- in principle. Think __setitem__,
> __getitem__, __hash__, and __eq__. For example:
>
> >>> exec('cnt = 42; cnt = 43; cnt', NoisyNS())
> __setitem__('cnt', 42)
> __hash__('cnt')
> __setitem__('cnt', 43)
> __hash__('cnt')
> __eq__('cnt', 'cnt')
> __getitem__('cnt')
> __eq__('cnt', 'cnt')
>
> It's reasonable to assume a namespace uses a built-in dict and str
> keys (names) -- or at least types that don't do anything unusual that
> introduces concurrency problems.
This doesn't show a potential concurrency problem. Calculating a hash
on "cnt" is independent of other threads; the actual work of
__setitem__ isn't visible in this view. There certainly are places
where a context switch could cause problems (eg resizing the dict),
but they're the dict's problem, not your Python program's - because
there's no way you could acquire a lock without working with these
same issues.
This, btw, is why CPython has the GIL - it's the most efficient way to
solve all these problems. Removing the GIL means putting explicit
locks around these kinds of risk points, and explicit locks are slow,
so one lock (the GIL) is way faster than many locks.
ChrisA
--
https://mail.python.org/mailman/listinfo/python-list
