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. _______________________________________________ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
