Parallelism is a physical thing, concurrency is a logical thing.
Fundamentally the difficulty is all about synchronization. People can try to split hairs and say there are two terms for two different things but ultimately it doesn't matter because the underlying problem is the same.
Parallelism is a physical thing, concurrency is a logical thing.
So by your own definition, wouldn't multi-core concurrency be parallelism?
The point I'm trying to make is down to brass tacks, single core concurrency is a lot simpler than multi core concurrency, because you don't need any hardware cooperation.
Concurrency isn’t necessarily parallel.
There are still plenty of single core systems out there running concurrent software, even today, for example embedded systems.
Yes it does. If you have two threads which (for whatever reason) are sharing memory and they can be run in an arbitrary order, you have to deal with memory synchronization. If it's a single core machine, you still need to synchronize your memory access. Mutexes and semaphores predate systems with multiple processors.
The claim you repeat is meaningless. A program is either parallel / concurrent or not. The situation you describe (when there's a single processor core) isn't parallel or concurrent. In some sense, it emulates concurrent / parallel execution because it imitates the unpredictable ordering of code execution, which sure has its uses... but the whole point of dealing with this unpredictable ordering is that we actually want parallelism / concurrency. The emulation on its own is worthless.
a program which is not written as concurrent can never be executed as parallel
a program which is written as concurrent can be executed as parallel, or not
> The situation you describe (when there's a single processor core) isn't parallel or concurrent.
a program running on a single core can never be parallel, but it can be concurrent
concurrent is a logical property, parallel is a physical property
Unless of course you're running multiple independent instances of it, each with different parameters, which I gather is a pretty common way of running long running CPU- intensive operations on large data sets. Presumably there's often some final separate step that may be needed to combine the results once they're all finished, which if run manually obviates any concurrency concerns at the software level.
("a program [as executed]" is a single instance (process) of a binary)
If only these "Gophers" knew anything about computing history!
Even in modern times, we have something like the first generation raspberry pi zero, it has a single ARM core, and it multitasks fine.