# Behavior of \`Threads.@threads for\` loop

**URL:** https://discourse.julialang.org/t/behavior-of-threads-threads-for-loop/76042
**Category:** General Usage
**Tags:** multithreading
**Created:** [February 8, 2022, 7:31pm UTC](https://discourse.julialang.org/t/behavior-of-threads-threads-for-loop/76042 "2022-02-08T19:31:36Z")
**Posts on this page:** 1
**Showing post:** 17

<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: [February 14, 2022, 5:44am UTC](https://discourse.julialang.org/t/behavior-of-threads-threads-for-loop/76042/17 "2022-02-14T05:44:19Z")

</div>

> [@jling](#):
>
> you have as many tasks as the number of iterations right?

No, `@threads` currently spawns only `nthreads()` tasks, and each task processes a contiguous region of the input. In the _current_ implementation, the task tree structure of `:dynamic` and `:static` is identital. The only difference is that the underlying tasks in `:dynamic` can be scheduled on an arbitrary worker thread and is allowed to migrate across worker threads, like the usual tasks created via `Threads.@spawn`.

The details may change in the future but I believe the number of tasks will always be `O(nthreads())` and each task process one contiguous region (or a few contiguous regions). I’m almost certain this will always be the case since otherwise, it’d be essentially equivalent to `@sync for x in xs; @spawn ...; end`.

(This is not apparent from the current docstring [Multi-Threading · The Julia Language](https://docs.julialang.org/en/v1.8-dev/base/multi-threading/#Base.Threads.@threads) and so we probably should add some more clarifications.)

---

_[View the full topic](https://discourse.julialang.org/t/behavior-of-threads-threads-for-loop/76042)._