Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 22 May 2001 22:46:38 +0900
From:      Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp>
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
Message-ID:  <200105221346.f4MDkcD91792@rina.r.dl.itc.u-tokyo.ac.jp>
In-Reply-To: In your message of "Tue, 22 May 2001 21:58:10 %2B0900" <200105221258.f4MCwAD85296@rina.r.dl.itc.u-tokyo.ac.jp>
References:  <200105220637.f4M6bDD40713@rina.r.dl.itc.u-tokyo.ac.jp> <XFMail.010522044838.jhb@FreeBSD.org> <200105221258.f4MCwAD85296@rina.r.dl.itc.u-tokyo.ac.jp>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 22 May 2001 21:58:10 +0900,
  Seigo Tanimura <tanimura> said:

Seigo> On Tue, 22 May 2001 04:48:38 -0700 (PDT),
Seigo>   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.

Seigo> If you do not protect both p_pgrp and p_pglist in struct proc by an
Seigo> identical lock, you end up with breaking either setpgid(2) or kill(2)
Seigo> for a process group. The following scenario depicts an example of the
Seigo> breakage:

BSD/OS seems to solve that problem by having p_session in struct
proc, and protecting p_pgrp by the mutex of both a process and a
session. Then you have to lock a session as well as a process prior to
reading p_pgrp, as I locked proctree_lock.

I chose proctree_lock because deleting a process group may call
funsetown(), which calls free(9). Maybe we can reconsider protecting
by a session lock when free(9) becomes not to lock lockmgr.

-- 
Seigo Tanimura <tanimura@r.dl.itc.u-tokyo.ac.jp> <tanimura@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?200105221346.f4MDkcD91792>