tweaks

Author: IanButterworth

base/threadingconstructs.jl

@@ -233,8 +233,8 @@ For example, the above conditions imply that:
 - Communicating between iterations using blocking primitives like `Channel`s is incorrect.
 - Write only to locations not shared across iterations (unless a lock or atomic operation is
   used).
-- The value of [`threadid()`](@ref Threads.threadid) may change even within a single
-  iteration. See [`Task Migration`](@ref man-task-migration)
+- Unless the `:static` schedule is used, the value of [`threadid()`](@ref Threads.threadid)
+  may change even within a single iteration. See [`Task Migration`](@ref man-task-migration).
 
 ## Schedulers
 

doc/src/manual/multi-threading.md

@@ -454,11 +454,13 @@ threads in Julia:
 
 ## [Task Migration](@id man-task-migration)
 
-After a task starts running on a certain thread (e.g. via [`@spawn`](@ref Threads.@spawn) or
-[`@threads`](@ref Threads.@threads)), it may move to a different thread if the task yields.
+After a task starts running on a certain thread it may move to a different thread if the task yields.
 
-This means that [`threadid()`](@ref Threads.threadid) should not be treated as constant within a task, and therefore
-should not be used to index into a vector of buffers or stateful objects.
+Such tasks may have been started with [`@spawn`](@ref Threads.@spawn) or [`@threads`](@ref Threads.@threads),
+although the `:static` schedule option for `@threads` does freeze the threadid.
+
+This means that in most cases [`threadid()`](@ref Threads.threadid) should not be treated as constant within a task,
+and therefore should not be used to index into a vector of buffers or stateful objects.
 
 !!! compat "Julia 1.7"
     Task migration was introduced in Julia 1.7. Before this tasks always remained on the same thread that they were