# Questions on parallel programming terminology

**URL:** <https://discourse.julialang.org/t/questions-on-parallel-programming-terminology/38996>\
**Category:** Julia at Scale\
**Tags:** question, parallel, distributed, threads\
**Created:** [May 8, 2020, 1:21am UTC](https://discourse.julialang.org/t/questions-on-parallel-programming-terminology/38996 "2020-05-08T01:21:51Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![tkf](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tkf/32/17635_2.png) [@tkf](https://discourse.julialang.org/u/tkf)\
**Post date:** [May 8, 2020, 3:00am UTC](https://discourse.julialang.org/t/questions-on-parallel-programming-terminology/38996/2 "2020-05-08T03:00:26Z")

</div>

> [@juliohm](#):
>
> refers to real threads as `1:Threads.nthreads()` , correct?

Yes, if what you mean by “real thread” is OS thread.

> [@juliohm](#):
>
> From what I grasped, “green threads” aren’t real threads, what are they then? Should new users learn about them at all?

I think it depends. If you want to, say, implement something like `pmap`, you probably should. But if you just want to use `pmap` then it’s probably OK to forget about it.

> [@juliohm](#):
>
> First, I understand that these three concepts are restricted to process pools, so nothing to do with threads.

Channels and futures in general are communication mechanisms in **concurrent** programming. The Julia type `Channel` can be used for communication _within_ a process and `RemoteChannel` and `Future` are for communication _across_ processes. So, `Channel` cannot be used with a process pool (but it can be used with _thread_ pool; e.g., with `@spawn` and `@threads`).

(Though looking at the second question, maybe you already get this idea?)

Note my emphasis on _concurrency_ and not _parallelism_. The difference is a bit subtle and I’m not sure everybody agrees with a single definition. But I like this explanation by Rob Pike:

[![](https://global.discourse-cdn.com/julialang/original/3X/5/f/5f828c1d33b772b4e84c49d9bb6d26ab9b02bd39.jpeg "Concurrency Is Not Parallelism") ](https://www.youtube.com/watch?v=qmg1CF3gZQ0)

I’m bringing it up because you may be confused that `Channel` is used even without threading, i.e., parallelism. Concurrency is about dealing with multiple things at once so `Channel` is useful even though you use only one CPU (e.g., using `@async`).

> [@juliohm](#):
>
> Third, I understand that a `Future` is just a channel that is returned by a remote function call?

`Future` can be used for passing at most one value (or an exception) to the peer while `RemoteChannel` can be used for passing arbitrary number of values.

> [@juliohm](#):
>
> Can we submit work to remote processes running on remote machines, and use multi-threading there with a specific number of real `Threads` threads instead of “green threads” as well?

I don’t think you can do it just with Distributed. One option is to use Transducers.jl: [Thread- and process-based parallelisms in Transducers.jl (+ some news)](https://discourse.julialang.org/t/thread-and-process-based-parallelisms-in-transducers-jl-some-news/32285)

> [@juliohm](#):
>
> Also, this functionality needs to necessarily live in `pmap` ? How to deal with this hybrid type of parallelism more explicitly?

I think we need more high-level abstractions and easy-to-use APIs, developed outside stdlib.

> [@juliohm](#):
>
> I couldn’t get however the `remote_do` documentation. What is it?

The documentation says

> Unlike `remotecall`, it does not store the result of computation, nor is there a way to wait for its completion.

So, it’s just an API that does not send back the result by default. You need to use `RemoteChannel` etc. for communication.

---

_[View the full topic](https://discourse.julialang.org/t/questions-on-parallel-programming-terminology/38996)._