Another illustration that with race conditions all hell can break loose. It's not only about data corruption or deadlocks. This case is explored in depth which is nice, also compared across several languages.

Nice performance comparison of file handling in multithreaded context. It's surprising how slow MacOS seems to be there.

What do you want? Speed or safety? Ultimately you'll have to choose one.

Looks like a nice resource to handle the coming move to free threaded Python.

A harsh reminder that getenv is not thread safe...

This is a neat broad introduction about the problems you will encounter when multiple threads are involved and how to approach them.

Nice results. Interesting implementation too. I wonder if some of it will make its way to the glibc or musl.

Or why going through an event loop might be more work initially but will make some things easier longer term. Nice way to frame how threads are bringing some opaque state.

Good reminder of what OS threads entails and why they can't be optimized much further. There's so much you can do properly in userland.

Looks like an interesting tool to analyze hard to reproduce bugs, especially when concurrency is involved. This could be useful to find the source of flaky tests as well.

In which case you want one or the other? This is illustrated in the Rust case which has its own struggles, but the question applies more largely in my opinion.

It's hard to argue that the Rust type system isn't superior to the C++ type system... it's definitely nice how it actively prevents data races at compile time.

Very interesting tools for testing and verifying concurrent code.

Very interesting talk. It gives a good idea of some properties of the JVM memory model. It also shows how the CPU architecture properties can leak all the way through changing some of the behavior of JVM code. Too bad this particular thing seems badly documented on the JDK side.

This is unsurprisingly highly depend on the actual code, not only on the hardware.

Good reminder that false sharing is a real thing. It's easier to encounter than you think when you start to dabble into multi-threading.

Won't be easy to get rid of the GIL in the Python ecosystem. There are notable differences of behavior between implementations and even versions of the same implementation... Lots of user code will unwillingly depend on a specific set of guarantees.

Good way to understand two phase locking better, its tradeoffs, variants and how it's been improved.

OK, this could be big for Python. Let's see how they execute this plan. It carries some risks as well, but they seem well aware of them.

This apparently needs to be reminded from time to time. So here it is: don't expect those timestamps to be unique, even on a single machine.