Date: Wed, 23 May 2001 10:21:01 -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.010523102101.jhb@FreeBSD.org> In-Reply-To: <200105231123.f4NBNUD33639@rina.r.dl.itc.u-tokyo.ac.jp>
next in thread | previous in thread | raw e-mail | index | archive | help
On 23-May-01 Seigo Tanimura wrote: > The issue of both of the solutions briefed above is that the p_pgrp > lock protects *excess* data. It might be another solution to introduce > a new mutex (p_pgrpmtx) into struct proc to lock p_pgrp. Although > memory size costs per process, contention for p_pgrp lock should occur > much less than to adopt a session lock or a global lock. > > As psignal() and some other functions also read p_pgrp, p_mtx should > also lock p_pgrp. You lock either p_pgrpmtx or p_mtx to read p_pgrp, > and both of the locks to modify p_pgrp. Sounds good. I would just use a global p_grp lock for now. It can always be changed to be more fine-grained later if desired. -- 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.010523102101.jhb>