On Oct 10, 2:37pm, [email protected] (Taylor R Campbell) wrote: -- Subject: Re: Anomalies while handling p_nstopchild count
| Date: Sat, 10 Oct 2015 13:49:52 +0000 (UTC) | From: [email protected] (Christos Zoulas) | | In article <[email protected]>, | Paul Goyette <[email protected]> wrote: | >-=-=-=-=-=- | >+ | >+ if (!mutex_tryenter(proc_lock)) { | >+ mutex_exit(p->p_lock); | >+ mutex_enter(proc_lock); | >+ mutex_enter(p->p_lock); | >+ } | | Can you find out where exit1() is called with the proc_lock held? Then | you can call it with an additional flag and remove the tryenter call, | and instead use the flag. | | 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... christos
