Is it just me or does the Go community use a different definition of "concurrency" vs "parallelism"? The "standard" one is afaict "parallelism is one way of getting concurrency", whereas Go seems to use it specifically to talk about interleaving.
-
-
In my understanding, yes.
-
How does this differ from Go's definition.
-
Go's definition makes concurrency and parallelism mutually exclusive, i.e. 1:1 kernel threading is parallel but not concurrent.
-
To be clear, this is my impression of Go's definition from seeing folks use it that way. Hence the "is it just me or".
End of conversation
New conversation -
-
-
Seems like the Go misunderstandings may stem from this: https://twitter.com/hashtag_lana/status/930630520626483200 …
This Tweet is unavailable.Thanks. Twitter will use this to make your timeline better. UndoUndo
-
-
-
This is correct.
-
Although, reading it again, it’s not precise. But...Twitter.
End of conversation
New conversation -
-
-
Parallelism is contention-free (e.g. VEX). Concurrency is contended (e.g. mutexes, spinlocks, interrupts/timers)
-
Thanks bro
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.