Going back to the concurrency vs parallelism (because the distinction is actually important), google search gives us:
-
wikipedia/Concurrent_computing (emphasis mine, I also separated paragraphs for easier readability):
The concept of concurrent computing is frequently confused with the related but distinct concept of parallel computing,[3][4] although both can be described as "multiple processes executing during the same period of time".
In parallel computing, execution occurs at the same physical instant: for example, on separate processors of a multi-processor machine, with the goal of speeding up computations—parallel computing is impossible on a (one-core) single processor, as only one computation can occur at any instant (during any single clock cycle).
By contrast, concurrent computing consists of process lifetimes overlapping, but execution need not happen at the same instant.
-
stackoverflow.com/what-is-the-difference-between-concurrency-and-parallelism - the top answer (emphasis mine):
Concurrency is when two or more tasks can start, run, and complete in overlapping time periods. It doesn't necessarily mean they'll ever both be running at the same instant. For example, multitasking on a single-core machine.
Parallelism is when tasks literally run at the same time, e.g., on a multicore processor.
Concurrency is not Parallelism by Rob Pike (the video that I linked before) also uses the same definitions. One may discard this talk as niche because it has only 130k views, but at the same time is it THE Rob Pike. The most relevant part of the talk starts at 1:40.
I would say that concurrency happens at design time. We split the problem into multiple independent entities and we make sure that those entities work correctly "by themselves". The solution to the whole problem is a composition of those smaller things.
Parallelism is simultaneous execution.
In Swift we only deal with concurrency: we write code, we design stuff. Actor re-entrancy is 100% concurrency problem. If you have this problem then your design (code) is not correct. You can have re-entrance problem (or more generall: concurrency problem) regardless of whether you have parallel execution or not.
Ordering is yet something different. It is more like a single manifestation of multiple ways the program can execute. From the concurrency pov (which is what we are interested in when writing Swift code): if you design is correct it should handle any order without arriving into undesired/inconsistent state.
TLDR: when writing Swift code we only deal with concurrency not parallelism.