I'm of the opinion that we chose the wrong term for concurrency. Concurrency means multiple things going on simultaneously, which is not what's happening with our version of it. Only one thing is happening at any given time, but the tasks are being multiplexed on a shared resource. Parallelism = concurrency, "concurrency" = multiplexing.

Maybe there's a more appropriate term than multiplexing, but I think that's certainly better than concurrency at describing it.

Data races and other race conditions are still present in concurrent systems without parallelism (of the actually executing at the same time sense, like with multiple cores). If they weren't, we wouldn't need most uses of mutexes and semaphores on single core processors. As the book gets into, concurrency is about multiple tasks that are arbitrarily interleaved with each other. That interleaving is why you can have data races and other errors even in a single core system.

Data races are covered: https://harmony.cs.cornell.edu/book/#sec-57

Threads+locking introduce data race issues into Harmony's model. As far as I can tell.

Programming with concurrency is hard. Concurrency can make programs faster than sequential ones, but having multiple threads read and update shared variables concurrently and synchronize with one another makes programs more complicated than programs where only one thing happens at a time. Why are concurrent programs more complicated than sequential ones? There are, at least, two reasons: The execution of a sequential program is usually deterministic: If you run the program twice with the same input, the same output will be produced. Bugs are reproducible and thus easy to track down, for example by instrumenting the program. They are called Bohrbugs. However, the output of running concurrent programs depends on how the execution of the various threads are interleaved. Some bugs may occur only occasionally and may never occur when the program is instrumented to find them. We call these Heisenbugs—overhead caused by instrumentation leads to timing changes that can make such bugs less likely to cause havoc. In a sequential program, each statement and each function can be thought of as happening atomically (indivisibly) because there is no other activity interfering with their execution. Even though a statement or function may be compiled into multiple machine instructions, they are executed back-to-back until completion. Not so with a concurrent program, where other threads may update memory locations while a statement or function is being executed.