3 ms·

I'm trying to wrap my head around this, not being familiar with Go yet... is this analogous to the difference between a Task and a Thread in the .net world?

jlouis 14y ago
A task is a future or a promise which can deliver a result later. A Goroutine in go is more general than a task because they don't have to terminate when they deliver a result. The subsume tasks in any way. Goroutines are mapped onto (kernel-level) threads in order to make it possible to run more of them at once and thus provide parallel execution. Otherwise, you have a single scheduler of goroutines in a single process. You can still switch context between the goroutines, thus the system is concurrent. But it will not be parallel: One goroutine only at a time. For a system in which most goroutines wait on IO or the network, it may not be a problem to run many goroutines on a single core only.
- magic_haze 14y ago
  I still don't quite follow. What do you mean by "terminate" a task? From my understanding, when a Task returned, the underlying Thread would be returned to the common pool for use by other Tasks. Does the Go scheduler detect when a task is blocked for IO, and reuse the thread for other goroutines?
- nivertech 14y ago
  "to make it possible to run more of them at once and thus provide parallel execution." I guess you meant "concurrent execution" here ;) "Otherwise, you have a single scheduler of goroutines in a single process. ... But it will not be parallel: One goroutine only at a time." So Go doesn't have something equivalent to SMP scheduler in Erlang?
smosher 14y ago
Suppose you have a process which is I/O bound on multiple I/O resources. If instead of blocking on each one, you suspend that sequence of execution and move onto the next, resuming when you get the signal that the call is unblocked, you are handling the resources concurrently, but not in parallel. If you alter the program to spawn a separate thread for each, and let them all block, you will have a parallel solution.
edouard1234567 14y ago
Concurrency : appears to be running at the same time (possibly using the same core) Parallelism : actually running at the same (using different cores)
ww520 14y ago
They are language agnostic generic concepts. Concurrency deals with dependency, or the lack of, among tasks and their running order. Task A must run after task B, B after C, etc. A, B, and C are not concurrent tasks. D can run at anytime. D can run before, after, or at the same time of A/B/C. The ordering doesn't matter. In this case D is concurrent to A/B/C. The concurrent tasks MIGHT run at the same time but it's not necessary. It's up to the OS/system scheduler. Concurrent tasks can run on a single core cpu serially and they are still concurrent tasks. Parallelism has to do with efficiently cranking as many tasks as possible to actually run in parallel. E.g. given 10 cpu, how do I fully utilize all the cpu at the same time? Mostly it has to do with data partition to make sure the cpu can get evenly distributed non-depending data. Concurrency and parallelism can be mixed at the same time. E.g. in the map-reduce pattern, the map part utilizes parallelism to distribute the data to process at all the cpu. The reduce task has dependency on the mpa tasks; running order means concurrency is in play there.

jlouis 14y ago

A task is a future or a promise which can deliver a result later. A Goroutine in go is more general than a task because they don't have to terminate when they deliver a result. The subsume tasks in any way. Goroutines are mapped onto (kernel-level) threads in order to make it possible to run more of them at once and thus provide parallel execution. Otherwise, you have a single scheduler of goroutines in a single process. You can still switch context between the goroutines, thus the system is concurrent. But it will not be parallel: One goroutine only at a time. For a system in which most goroutines wait on IO or the network, it may not be a problem to run many goroutines on a single core only.

magic_haze 14y ago
I still don't quite follow. What do you mean by "terminate" a task? From my understanding, when a Task returned, the underlying Thread would be returned to the common pool for use by other Tasks. Does the Go scheduler detect when a task is blocked for IO, and reuse the thread for other goroutines?
nivertech 14y ago
"to make it possible to run more of them at once and thus provide parallel execution." I guess you meant "concurrent execution" here ;) "Otherwise, you have a single scheduler of goroutines in a single process. ... But it will not be parallel: One goroutine only at a time." So Go doesn't have something equivalent to SMP scheduler in Erlang?

smosher 14y ago

Suppose you have a process which is I/O bound on multiple I/O resources. If instead of blocking on each one, you suspend that sequence of execution and move onto the next, resuming when you get the signal that the call is unblocked, you are handling the resources concurrently, but not in parallel. If you alter the program to spawn a separate thread for each, and let them all block, you will have a parallel solution.

edouard1234567 14y ago

Concurrency : appears to be running at the same time (possibly using the same core) Parallelism : actually running at the same (using different cores)

ww520 14y ago

They are language agnostic generic concepts. Concurrency deals with dependency, or the lack of, among tasks and their running order. Task A must run after task B, B after C, etc. A, B, and C are not concurrent tasks. D can run at anytime. D can run before, after, or at the same time of A/B/C. The ordering doesn't matter. In this case D is concurrent to A/B/C. The concurrent tasks MIGHT run at the same time but it's not necessary. It's up to the OS/system scheduler. Concurrent tasks can run on a single core cpu serially and they are still concurrent tasks. Parallelism has to do with efficiently cranking as many tasks as possible to actually run in parallel. E.g. given 10 cpu, how do I fully utilize all the cpu at the same time? Mostly it has to do with data partition to make sure the cpu can get evenly distributed non-depending data. Concurrency and parallelism can be mixed at the same time. E.g. in the map-reduce pattern, the map part utilizes parallelism to distribute the data to process at all the cpu. The reduce task has dependency on the mpa tasks; running order means concurrency is in play there.