tech-kern archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: Anomalies while handling p_nstopchild count
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
Home |
Main Index |
Thread Index |
Old Index