Date: Thu, 5 Oct 2000 12:40:16 +1100 (EST) From: Bruce Evans <bde@zeta.org.au> To: Matt Dillon <dillon@earth.backplane.com> Cc: Peter Wemm <peter@netplex.com.au>, Chuck Paterson <cp@bsdi.com>, Alfred Perlstein <bright@wintelcom.net>, John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG, John Polstra <jdp@polstra.com>, Daniel Eischen <eischen@vigrid.com>, Greg Lehey <grog@lemis.com> Subject: Re: Mutexes and semaphores Message-ID: <Pine.BSF.4.21.0010051216130.12069-100000@besplex.bde.org> In-Reply-To: <200010041639.e94GdVR24384@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 4 Oct 2000, Matt Dillon wrote:
[Writing reordered to reply after quoted material]
[Peter Wemm wrote]
> :int
> :getppid(p, uap)
> : struct proc *p;
> : struct getppid_args *uap;
> :{
> : struct proc *parent;
> : pid_t pid;
> :
> : parent = p->p_pptr;
> : pid = parent->p_pid;
> :#ifdef SMP
> : for (;;) {
> : __asm __volatile (": : : memory"); /* mb(); on x86 */
> : if (parent == p->p_pptr)
> : break;
> : /* lost a race, our parent died and we reparented - redo */
> : parent = p->p_pptr;
> : pid = parent->p_pid;
> : }
> :#endif
> : p->p_retval[0] = (register_t)pid;
> : return 0;
> :}
> This is one of the few things I really hate in the linux source base.
This seems to be only to win getppid() benchmarks. Complications like it
might be justified in inner loops of syscalls that are called somewhat
more than once at most in normal programs. It's too hard to do things
this in the thousands of places that would be necessary to get a uniform
speedup.
> Besides, it isn't guarenteed to work. What happens if the process
> double-reparent's and the space pointed to by the original pptr is
> reallocated and reused in the second reparenting? That is, this
> Now, granted, the chance of the above occuring is probably close to nil.
> From an algorithmic point of view, though, the below code (and the
> linux code) cannot actually guarentee correct operation without also
> make assumptions on side effects (for example, in regards to who is
> or is not actually allowed to become the new parent and whether the
> situation can occur with those restrictions in place).
I think we know that only init can become the new parent provided we can
assume that the pointer access to determine to parent is atomic.
> I would prefer not to see this sort of code in FreeBSD, even if it means
> slowing things down a little.
I agree. Locking for file accesses slows things down much more, but not
significantly except for too-small i/o sizes.
Bruce
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0010051216130.12069-100000>