4 ms·

I'm having a hard time understanding where you would want concurrency without the benefit of parallelism where available? I also personally consider the idea of

I'm having a hard time understanding where you would want concurrency without the benefit of parallelism where available? I also personally consider the idea of single-core concurrency as "not parallelism" to be semantics. It may not be truly parallel, but both routines are getting CPU time in the same algorithm, so, in terms of programmatic considerations, to me the two (at least with Go) are basically the same.

justincormack 10y ago
So you don't need locking.
- wyager 10y ago
  Non-parallel (perpendicular?) green threads are semantically indistinguishable from parallel green threads. If you need locks with parallelism, you need them with green threads. Any locking unique to parallelism is handled by the runtime.
deleted 10y ago
[deleted]
cfallin 10y ago
Concurrency implies multiple partial computations in progress, but not necessarily that they run at the same time -- some models (e.g. a single-threaded event loop, like Node's) explicitly guarantee mutual exclusion and define certain preemption points. Cooperative multitasking, single-threaded event loops, and futures/promises (when not pushed to a thread pool) are good examples. (I've also seen definitions of concurrency that do not imply the above, but I think the above definition is more in line with the distinction people try to make...)
barrkel 10y ago
Concurrency models the nondeterminism of the world outside the program. Parallelism is a performance improvement, at the cost of synchronisation for shared data. The two are orthogonal. Many programs are better written using concurrent primitives; whether they are better of with parallelism is a separate optimisation subject to tradeoffs, like all optimisations. If you can live without preemption, a single threaded world is no bad thing for correctness. Everything that touches the outside world (blocks) may be a green thread switch point though, so it's no panacea. Without hardware executing code in parallel, it's not parallelism, BTW. It's not semantics; it's specific jargon that means something.

justincormack 10y ago

So you don't need locking.

wyager 10y ago
Non-parallel (perpendicular?) green threads are semantically indistinguishable from parallel green threads. If you need locks with parallelism, you need them with green threads. Any locking unique to parallelism is handled by the runtime.

deleted 10y ago

[deleted]

cfallin 10y ago

Concurrency implies multiple partial computations in progress, but not necessarily that they run at the same time -- some models (e.g. a single-threaded event loop, like Node's) explicitly guarantee mutual exclusion and define certain preemption points. Cooperative multitasking, single-threaded event loops, and futures/promises (when not pushed to a thread pool) are good examples. (I've also seen definitions of concurrency that do not imply the above, but I think the above definition is more in line with the distinction people try to make...)

barrkel 10y ago

Concurrency models the nondeterminism of the world outside the program. Parallelism is a performance improvement, at the cost of synchronisation for shared data. The two are orthogonal. Many programs are better written using concurrent primitives; whether they are better of with parallelism is a separate optimisation subject to tradeoffs, like all optimisations. If you can live without preemption, a single threaded world is no bad thing for correctness. Everything that touches the outside world (blocks) may be a green thread switch point though, so it's no panacea. Without hardware executing code in parallel, it's not parallelism, BTW. It's not semantics; it's specific jargon that means something.