Let us say I spin up a certain number of threads, julia -t 5. Is it possible to uniquely identify which thread is running my code at some point in time? I don’t mean threadid(), unless that is guaranteed to be unique.
I am confused what you ask for if threadid is not the answer. threadid gives you the ID of the thread that currently runs your code. This is not guaranteed to be fixed so calling threadid again later might give a different answer because your code is executed by another thread then.
What do you mean by “uniquely identify the thread that is running my code at some point in time”? And why is threadid not the answer?
3 Likes
threadid does give you the thread at any point in time. It is just wrong to assume that it will be fixed/constant throughout the lifetime of the task.
2 Likes
1 Like
Right, I know that threadid() executing my code can change (thanks!).
What I was not sure about was: I start 5 threads, but I start only 4 tasks by spawn. I want to know which threads the tasks are running on (in the sense of statistics).
So, I think you guys are saying the threads are given ids when spun up, and those will not change arbitrarily?
It seems the question is now moot. See Surprising behavior for default/interactive thread pools · Issue #53217 · JuliaLang/julia · GitHub
Yes, Julia threads have IDs that don’t change and threadid() is the function to query the ID of the thread that is currently running a task.
As you know, by default, tasks can migrate between threads. Hence, there is no naive task->thread mapping because different parts of a task might run on different threads. Of course, you can opt out of task migration with, e.g., OhMyThreads.@spawnat or @threads :static to “solve” this. Another way is to track the migration of the task, e.g. by calling threadid() multiple times (basically sampling the current threadid) and storing the results for each task. To this end, something like OhMyThreads.Tools.taskid() could be useful to (almost certainly uniquely) identify the task. It essentially is a task-pendant for threadid().
I don’t see how this issue is relevant for the question here. The issue is about the thread pool of the main thread not thread ids.
Because the answers in that issue will probably have a bearing on what I wanted to investigate with the thread id statistics.