Date: Sat, 10 Oct 2015 11:15:20 -0400 From: [email protected] (Christos Zoulas)
On Oct 10, 2:37pm, [email protected] (Taylor R Campbell) wrote: -- Subject: Re: Anomalies while handling p_nstopchild count | I don't think that's why he put that there -- it's just that the lock | order is proc_lock first, then p->p_lock for any p. This is the | optimistic reverse-order locking fragment that the mutex(9) man page | suggests. Yes, but if you know proc_lock is not being held, calling tryenter is not an optimization! The man page should be clarified that the example checks and corrects the lock order *if it was broken*. Unless I am missing something obvious... proc_lock may be held by another thread even if the caller is guaranteed not to hold it. The other thread may furthermore be waiting on p->p_lock, in which case acquiring p->p_lock here would lead to deadlock -- but mutex_tryenter would simply fail. The optimization is to optimistically assume nobody else is holding proc_lock and do mutex_tryenter. Otherwise, we back out and acquire both locks in the correct order.
