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.