Hacker News Reader

Comment by hellofunk | Hacker News Reader

>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.

View on HN

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.

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.

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.

So you don't need locking.

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.

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...)

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.

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_...

Reply on news.ycombinator.com