I would say concurrency is more of a way of organizing code into independent parts. If you have multiple contexts, logically separable, and they can execute in

I would say concurrency is more of a way of organizing code into independent parts. If you have multiple contexts, logically separable, and they can execute independently you end up with some form of concurrent design. The reason people often think of coroutines (like generators resuming) vs routines (functions) as concurrent vs not concurrent has everything to do with contexts that can be thought of as executing in a non-deterministic order. Certainly there might be external dependencies that "force" an ordering to execution, but at the end of the day, it's the independence of an operation/computation that makes it concurrent with another. Concurrency can give rise to opportunities for things to execute in parallel, but it does not require them. Parallelism is therefore a condition of execution/evaluation. On a uniprocessor unix kernel, processes execute concurrently. On a multiproccessor unix kernel, you hope for parallel execution of processes (though they may be totally unrelated in context or goal), but you always maintain the concurrency. The scheduler pauses and switches contexts. The ability to switch contexts seems fairly equivalent to concurrency. And I don't think much else is needed. I'm not sure that's 100% correct, but it's how I like to think of this situation.