The manual states: The @threads macro executes the loop body in an unspecified order and potentially concurrently. It does not specify the exact assignments of the tasks and the worker threads. The assignments can be different for each execution. The loop body code (including any code transitively…

[image] PetrKryslUCSD: Good points, everyone. To make my concern concrete: Consider the function function f(a) th = Base.Threads.threadid() ... some code a[th] = 1 ... some code th = Base.Threads.threadid() return a[th] == 1 ? 5 * a[th] : 0 end Quite generally, th…

[image] PetrKryslUCSD: What I wonder is: can one make an assumption that when a function gets called with an a loop body, the entire function body will be executed by single thread? No.

[image] PetrKryslUCSD: What I wonder is: can one make an assumption that when a function gets called with an a loop body, the entire function body will be executed by single thread? For the function in question, if you do not use @threads on the loop that calls it, can you know that the entir…

The function could use @threads internally, not to mention that due to task preemption, the task executing the loop could move between threads.

Good points, everyone. To make my concern concrete: Consider the function function f(a) th = Base.Threads.threadid() ... some code a[th] = 1 ... some code th = Base.Threads.threadid() return a[th] == 1 ? 5 * a[th] : 0 end This function takes an argument which is suppose…

I think I chanced upon the solution: the argument :static for the @threads macro should guarantee what I want. a = fill(0, Base.Threads.nthreads()) Base.Threads.@threads :static for th in 1:Base.Threads.nthreads() b = f(a) end

Note that the solution in this other thread isn’t quite accurate anymore, because the default scheduler of @threads has changed from :static to :dynamic in Julia 1.8 . It’s pretty simple: With default options, neither @threads nor @spawn creates (thread-)sticky tasks. Hence, there are no guarantees …

[image] carstenbauer: For the reasons mentioned above, unless you have a good reason (which you might or might not have), you should try to think in terms of task-local storage rather than thread-local storage. For this, things like Base.task_local_storage and ChunkSplitters.jl might be helpfu…

[image] carstenbauer: Quite generally, threadid() is a footgun. Why? Because, as I indicated in my previous post, the default macros create non-sticky tasks, so the return value of threadid() can vary over the course of executing a piece of code. Fundamentally, this is because Julia offers task-…

[image] uniment: would it make sense to have a taskid()? It would have more or less the same potential pitfalls as the current threadid() (other than being presumably a constant per task); that is, making an array of a fixed size and indexing it with taskid() can have hidden dataraces if you …

Behavior of threads

General Usage

PetrKryslUCSD March 9, 2023, 1:51am 7

Also relevant: Behavior of `Threads.@threads for` loop
With solution by @carstenbauer

Topic		Replies	Views
No more threadid indexing? [thread-local storage] Performance multithreading , threads	36	1408	August 15, 2025
PSA: Thread-local state is no longer recommended; Common misconceptions about threadid() and nthreads() General Usage announcement , multithreading	58	4786	April 30, 2024
Behavior of `Threads.@threads for` loop General Usage multithreading	30	5365	February 14, 2022
Multithreading with shared memory caches Performance question , performance , multithreading	27	2176	June 13, 2023
Sharp edge with `Threads.threadid()` and task migration General Usage multithreading	64	1645	February 12, 2025

Behavior of threads

Related topics