5 ms·
The GIL does very little to protect unexperienced users. It's still really easy to run into race conditions, for example, if your thread gets scheduled out in a
by n2d4 3y ago
The GIL does very little to protect unexperienced users. It's still really easy to run into race conditions, for example, if your thread gets scheduled out in any multi-instruction operation (this is more common than you think [1]). In general, Python code still has to be thread-safe; you get the risks without the benefits.
If you don't care about CPU performance, instead of threads you should go for an event-loop approach (see asyncio in Python). As soon as you have threads (on a language-level, not implementation-level), there is some notion of implicit switching, and you run into issues. So, the language you're looking for is JavaScript, which is single-threaded and every context switch is explicit (in form of `await` or `yield`).
[1] https://verdagon.dev/blog/python-data-races https://verdagon.dev/blog/python-data-races
- paulddraper 3y ago> this is more common than you think Like, for example, count += 1 --- The GIL primarily protects C code, not Python code.
- asvitkine 3y agoI don't think the blog you cite backs up your claim of "it's still really easy to run into race conditions". The author literally says: "This was actually pretty hard to discover. The first few experiments failed, because Python is pretty smart about when it runs each thread." But I think the main way the GIL protects inexperienced users is that its presence has the effect that Python code using the threading APIs is very uncommon, since those APIs don't currently provide parallel computation (only parallel IO). So inexperienced users are protected due to 99% of Python programs not using multithreading as a result (and so likely the one they're developing also doesn't), whereas this will presumably change when the limitations imposed by the GIL go away.
- mlyle 3y ago> I don't think the blog you cite backs up your claim of "it's still really easy to run into race conditions". > The author literally says: "This was actually pretty hard to discover. The first few experiments failed, because Python is pretty smart about when it runs each thread." I completely disagree here with your reading. Rare race conditions are much worse than races you trip over frequently.
- n2d4 3y agoMore precise wording would've been: "It's still really easy to write code that runs into race conditions". The race conditions are rare, but code that (rarely) causes them isn't.