Should have been titled "Is Parallel Programming What Can You Hard, And, If So, Do About It?"

I would probably recommend the art of multiprocessor programming (herlihy and shavitz) as a good starting point for concurrent programming. There is also " A primer on memory consistency and cache coherence" (Nagarajan et al) if you want to get more into the interaction between memory consistency and coherence.

What can you do about it?

Ask Claude, which has read all the existing literature on parallel programming, to make the program faster.

This review seems to equate parallelism and concurrency as the same thing and they are not.

As I understand it, the parallelism is about task execution and concurrency is about task structure. Or, as Rob Pike said:

"Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once."

He said that in his Concurrency is not Parallelism talk.

Parallel programming is a great application for LLM correctness proofs in Lean.

You can't unit test your way out, but if you care about the code's correctness, today there's a way.

Nope! Parallel programming is all yahoo, wee, look at that go!

Then comes the parallel debugging.

Pretty soon it's 15 years later, different person, yahoo-wee bro having long moved on.