From owner-freebsd-current Wed May 23 4:23:39 2001 Delivered-To: freebsd-current@freebsd.org Received: from rina.r.dl.itc.u-tokyo.ac.jp (rina.r.dl.itc.u-tokyo.ac.jp [133.11.199.247]) by hub.freebsd.org (Postfix) with ESMTP id 098C137B424; Wed, 23 May 2001 04:23:34 -0700 (PDT) (envelope-from tanimura@r.dl.itc.u-tokyo.ac.jp) Received: from rina.r.dl.itc.u-tokyo.ac.jp (localhost [127.0.0.1]) by rina.r.dl.itc.u-tokyo.ac.jp (8.11.3+3.4W/3.7W-rina.r-20010412) with ESMTP id f4NBNUD33639 ; Wed, 23 May 2001 20:23:31 +0900 (JST) Message-Id: <200105231123.f4NBNUD33639@rina.r.dl.itc.u-tokyo.ac.jp> Date: Wed, 23 May 2001 20:23:30 +0900 From: Seigo Tanimura To: jhb@FreeBSD.org Cc: tanimura@r.dl.itc.u-tokyo.ac.jp, current@FreeBSD.org Subject: RE: New strategy of locking a process group In-Reply-To: In your message of "Tue, 22 May 2001 07:56:52 -0700 (PDT)" References: <200105221258.f4MCwAD85296@rina.r.dl.itc.u-tokyo.ac.jp> User-Agent: Wanderlust/1.1.1 (Purple Rain) SEMI/1.13.7 (Awazu) FLIM/1.13.2 (Kasanui) MULE XEmacs/21.1 (patch 14) (Cuyahoga Valley) (i386--freebsd) Organization: Digital Library Research Division, Information Techinology Centre, The University of Tokyo MIME-Version: 1.0 (generated by SEMI 1.13.7 - "Awazu") Content-Type: text/plain; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, 22 May 2001 07:56:52 -0700 (PDT), John Baldwin said: John> On 22-May-01 Seigo Tanimura wrote: >> On Tue, 22 May 2001 04:48:38 -0700 (PDT), >> John Baldwin 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: John> I'll have to look over the code in more detail, but I would encourage you John> to check the BSD/OS code. I did that last night, and figured out that there are two problems in FreeBSD under the scenario shown below: 1. Lock a process and obtain a process group via p_pgrp. 2. Lock the process list of the process group and traverse the list via p_pglist, locking each process in the list. 3. Lock each process in the list. That scenario induces the following problems: A. We have to lock two processes at once in order to traverse the list, namely p and LIST_NEXT(p, p_pglist) where p is a process in the list. B. We have to lock a process in 1 and 3 while locking a process group in 2, resulting in lock order reversal. BSD/OS solves the problem A by locking not a process but a process group to traverse the list. It should be worth implementing that solution in FreeBSD. In order to solve the problem B, a lock other than the process lock should protect p_pgrp. BSD/OS adopts the lock of a session accessible via p_session embedded in struct proc, while I attempt to apply a global lock. In any case, the aim of the p_pgrp lock is essentially for protecting *only* p_pgrp. Once we lock p_pgrp, we can compare pg_session (which requires no locks), lock a process group, a session or etc. until unlocking p_pgrp. 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. -- Seigo Tanimura To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message