Re: Anomalies while handling p_nstopchild count

[christos%zoulas.com@localhost (Christos Zoulas)]

On Oct 10,  2:37pm, campbell+netbsd-tech-kern%mumble.net@localhost (Taylor R Campbell) wrote:
-- Subject: Re: Anomalies while handling p_nstopchild count

|    Date: Sat, 10 Oct 2015 13:49:52 +0000 (UTC)
|    From: christos%astron.com@localhost (Christos Zoulas)
| 
|    In article <Pine.NEB.4.64.1510101636500.411%vps1.whooppee.com@localhost>,
|    Paul Goyette  <paul%whooppee.com@localhost> 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