On Sat, Mar 19, 2016 at 9:18 AM, Miod Vallat <[email protected]> wrote: > >> I'd like to know if dereferencing ``p_p'' is safe without holding the >> KERNEL_LOCK. > > SCHED_LOCK is enough to access p_p->ps_threads,
Uh, not quite. p_p itself is immutable for the life of a thread and can be dereferenced without locks. p_p->ps_threads (and p_thr_link) can only be modified by threads in this process. The result is that the test here can't claim the process is single-threaded when it's multi-threaded. (An "is MT" result can go stale if there's no locking and the only other thread in the process exits, but that's generally not an issue.) If you really need to walk the p_p->ps_threads list, then you currently need the kernel lock to keep the threads in it from disappearing. > The construct used to decide whether the process is multi-threaded > already appears twice in sys/kern¸ and your diff adds a third > instance. It is probably worth turning into a macro or an inline > function¸ to make sure there is no risk of the copies becoming > out-of-sync over time. I like this idea. Note that it should be a "am the only thread" or "do I have sibling threads" kind of predicate and not an "is this arbitrary process singled/multi-threaded?" test. Philip Guenther
