Date: Wed, 23 Feb 2005 16:00:17 +0200 From: Andrey Simonenko <simon@comsys.ntu-kpi.kiev.ua> To: John Baldwin <jhb@freebsd.org> Cc: Ashwin Chandra <ashcs@ucla.edu> Subject: Re: Kernel monitor, the return Message-ID: <20050223140017.GA256@pm514-9.comsys.ntu-kpi.kiev.ua> In-Reply-To: <200502221534.41979.jhb@FreeBSD.org> References: <000801c51327$0e2bf020$58e243a4@ash> <20050215132020.GA376@pm514-9.comsys.ntu-kpi.kiev.ua> <200502221534.41979.jhb@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Feb 22, 2005 at 03:34:41PM -0500, John Baldwin wrote: > > You don't need sched_lock to check PS_INMEM, proc lock is sufficient > (PS_INMEM is magic this way). I suggested the author of the original letter to get lock on sched_lock, because statclock() modifies ru_idrss and ru_isrss values and that values are read in that kproc. Having read some code in the kernel, now I think that lock on sched_lock is needed only before reading ru_idrss and ru_isrss for current thread. Am I right? (at least getrusage() does in this way.) In private letters we found that it is better to use _PHOLD/_PRELE for that task. > If you did though, you would lock proc first, then sched_lock. > You can _not_ lock a regular mutex (proc lock) after a spin > mutex (sched_lock) or you can deadlock. Thanks... mutex(9) also says about this. I've just looked at sources for mtx_lock_spin/unspin and for better understanding of meaning of the sentence you wrote.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050223140017.GA256>