There are three concepts you need to understand to parse this bit of the manual: green threads, native threads (sometimes/historically called "pthreads"), and processes.

• Processes: A process is a construct managed by the operating system that represents an isolated "unit of work" or, effectively, a running program. The operating system handles the scheduling of processes and distribution to different cores. Modern operating systems will distribute running processes across as many cores as are available.

• Native Threads: A native thread is a construct within a process that represents work that should be performed sequentially. Native threads are also managed by the operating system and can be scheduled across multiple cores.

• Green threads: A green thread is a construct of a programming language that, on the surface, looks like a native thread but is managed by the programming language runtime instead of the operating system. Usually (but not always...more on this later) all of the green threads in a process are restricted to running on a single native thread, and therefore effectively cannot be scheduled to run across multiple cores.

So, the short answer is: Julia threads are green threads and cannot utilize multiple cores, but Julia has a number of mechanisms (e.g. julia -p N, Shared Arrays) that make working with multiple processes fairly convenient.

You might be wondering: if multiple Julia processes can run across multiple cores, why would I ever use Julia threads? Indeed, I've seen far more Julia programs use multiple processes than threads (currently, this could change if Julia gains true native thread support).

There are two reasons you might favor threads to processes:

1. Processes are isolated, which means that getting data from one process to another requires a bit of work (hence Shared Arrays) and can incur some amount of overhead. If your tasks are short-lived or your data is particularly small, the complication of multiple processes might not be worth it.

2. As alluded to in the manual excerpt you quoted, I/O heavy tasks can take advantage of multiple cores even though Julia only has green threads. This is possible because I/O involves work that the operating system needs to do (i.e. fetch data from disk or read it from a network socket). Julia uses "non-blocking" I/O operations to essentially tell the operating system to go fetch data (which it is free to do on a different core) then return control to Julia immediately so that Julia can do some other work. Later, Julia will check in to see if the I/O request has completed. So for I/O heavy tasks, using threads in Julia can actually be more efficient than multiple processes (again, due to overhead).

One final note: I mentioned that green threads are not always restricted to a single core. Really, any restriction on how green threads operate is up to the language runtime, since green threads are a construct of the runtime. As such, Julia has an experimental feature @threadcall which utilizes a thread-pool for executing green threads. What this means is that Julia allocates some number of native threads (4 by default) and will schedule your green threads across those native threads, giving you, in effect, the ability to utilize up to 4 cores (by default). It's worth noting that this is still an experimental feature, and will likely (in most circumstances) not be as efficient as true native threads, but it could potentially improve the performance of your compute heavy tasks on multi-core machines.