Thread safety issue (I think) with defaultdict

Chris Angelico rosuav at gmail.com
Fri Nov 3 10:50:13 EDT 2017


On Fri, Nov 3, 2017 at 10:26 PM, Rhodri James <rhodri at kynesim.co.uk> wrote:
> On 02/11/17 20:24, Chris Angelico wrote:
>>
>> Thank you. I've had this argument with many people, smart people (like
>> Steven), people who haven't grokked that all concurrency has costs -
>> that threads aren't magically more dangerous than other options.
>
>
> I'm with Steven.  To be fair, the danger with threads is that most people
> don't understand thread-safety, and in particular don't understand either
> that they have a responsibility to ensure that shared data access is done
> properly or what the cost of that is.  I've seen far too much thread-based
> code over the years that would have been markedly less buggy and not much
> slower if it had been written sequentially.

Yes, but what you're seeing is that *concurrent* code is more
complicated than *sequential* code. Would the code in question have
been less buggy if it had used multiprocessing instead of
multithreading? What if it used explicit yield points? Multiprocessing
brings with it a whole lot of extra complications around moving data
around. Multithreading brings with it a whole lot of extra
complications around NOT moving data around. Yield points bring with
them the risk of locking another thread out unexpectedly (particularly
since certain system calls aren't async-friendly on certain OSes). All
three models have their pitfalls. It's not that threads are somehow
worse than every other model.

ChrisA



More information about the Python-list mailing list