On Thu, Jul 6, 2017 at 12:39 AM, eryk sun <eryk...@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 -- https://mail.python.org/mailman/listinfo/python-list
