Python threading and sharing variables

Chris Angelico rosuav at gmail.com
Wed Jul 5 12:04:51 EDT 2017


On Thu, Jul 6, 2017 at 12:39 AM, eryk sun <eryksun at gmail.com> wrote:
>> 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.
>
> The work in the above special methods is arbitrary bytecode that could
> do anything, and there's nothing to prevent a context switch here. The
> GIL provides no protection here. In principle it could be a problem,
> but in practice it is not.

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.

ChrisA



More information about the Python-list mailing list