4 ms·

>First of all, go() statement in Go language does parallelism in addition to simple green-threading. With all the talk about 'concurrency is not parallelism' th

>First of all, go() statement in Go language does parallelism in addition to simple green-threading. With all the talk about 'concurrency is not parallelism' that seems to be part of Go's DNA, I find the design decision to support both using a single statement a bit weird. Have to agree on this, and often wonder the same thing.

themartorana 10y ago
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.
eikenberry 10y ago
That's because parallelism is an optimization, not a programming abstraction. You might as well ask why function calls and inlined function calls don't have different statements. They certainly can (eg. C's inline keyword) but it is not necessary nor that important to inlining as an optimization.
- ruggeri 10y ago
  One difference is that inlining is a safe optimization in most contexts. Parallelizing a goroutine is not safe if the goroutine shares memory. Obviously that's not the default Go style, but sometimes sharing state is unavoidable. So that would be one point in favor of different syntax.
twotwotwo 10y ago
I like eikenberry's explanation of why in the sense of "what was the logic"; I speculated some on practical tradeoffs over on lobste.rs: https://lobste.rs/s/c8pxgu/performance_green_threads_why_it_matters/comments/fdus6y#c_fdus6y https://lobste.rs/s/c8pxgu/performance_green_threads_why_it_...

themartorana 10y ago

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.

eikenberry 10y ago

That's because parallelism is an optimization, not a programming abstraction. You might as well ask why function calls and inlined function calls don't have different statements. They certainly can (eg. C's inline keyword) but it is not necessary nor that important to inlining as an optimization.

ruggeri 10y ago
One difference is that inlining is a safe optimization in most contexts. Parallelizing a goroutine is not safe if the goroutine shares memory. Obviously that's not the default Go style, but sometimes sharing state is unavoidable. So that would be one point in favor of different syntax.

twotwotwo 10y ago

I like eikenberry's explanation of why in the sense of "what was the logic"; I speculated some on practical tradeoffs over on lobste.rs: https://lobste.rs/s/c8pxgu/performance_green_threads_why_it_matters/comments/fdus6y#c_fdus6y https://lobste.rs/s/c8pxgu/performance_green_threads_why_it_...