Some people use parallel and concurrent/multi-threaded interchangeably, yes.
However, parallelism refers to a quality of the code, not to how it's being executed. A program with a high level of parallelism will just run sequentially if there is only one thread to run on. Code with a low level of parallelism won't get executed concurrently when there are extra threads available.
Like I said in my previous post, parallel tasks are just tasks that don't have to be performed in a particular order. If you chop your application up in separate parallel tasks, they CAN be performed concurrently. That doesn't mean that they necessarily will be. A good example of this is running JavaScript in your browser. JavaScript promotes writing highly parallel code, using promises and callbacks. However, JavaScript also only runs on one thread in the browser. It's up to the browser to determine which task gets performed when.
Something similar is true for
Java when using multiple 'green' threads on a system that only has one core and no features like hyper-threading. If you use multiple threads, the thread scheduler will just switch between execution contexts every now and then, and the parallel tasks will appear to run at the same time, even though they're not really.
Here is an example of parallel code that isn't multi-threaded:
It's up to the implementation of the executor service in which order these tasks are performed. In practice,
helpMother() will be called before
helpFather(), but in theory this is not necessary. Helping mother and helping father are parallel tasks, but they are not performed concurrently.