Date: Tue, 22 May 2001 07:56:52 -0700 (PDT) From: John Baldwin <jhb@FreeBSD.org> To: Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> Cc: current@FreeBSD.org Subject: RE: New strategy of locking a process group Message-ID: <XFMail.010522075652.jhb@FreeBSD.org> In-Reply-To: <200105221258.f4MCwAD85296@rina.r.dl.itc.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On 22-May-01 Seigo Tanimura wrote: > On Tue, 22 May 2001 04:48:38 -0700 (PDT), > John Baldwin <jhb@FreeBSD.org> said: > > John> On 22-May-01 Seigo Tanimura wrote: >>> For now, p_mtx protects p_pgrp in struct proc. This is quite >>> troublesome for the following reason: > > John> Err, it doesn't really. It's mostly undecided at this point. Also, > have you > John> looked at the BSD/OS code on builder? They have process groups and > sessions > John> already locked not using global locks but using per-data structure > locks. > > If you do not protect both p_pgrp and p_pglist in struct proc by an > identical lock, you end up with breaking either setpgid(2) or kill(2) > for a process group. The following scenario depicts an example of the > breakage: I'll have to look over the code in more detail, but I would encourage you to check the BSD/OS code. > Finally, a fact missing in my last mail. psignal() actually checks for > the parent of a process, possibly sending SIGCHLD to it. This implies > that we have to slock proctree_lock so that the process hierarchy does > not change. Now that psignal() calls for both pgrpsess_lock and > proctree_lock, it should be cheaper to have only proctree_lock than > both of them. Actually, psignal does _not_ use proctree_lock. p_pptr is locked by both p_mtx and the proctree lock (writes to it require both locks) so either lock is sufficient to read the value. As a result, psignal() simply acquires p_mtx and doesn't go near proctree. -- John Baldwin <jhb@FreeBSD.org> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.010522075652.jhb>