From owner-freebsd-arch  Tue Oct  3 12:16:12 2000
Delivered-To: freebsd-arch@freebsd.org
Received: from fw.wintelcom.net (ns1.wintelcom.net [209.1.153.20])
	by hub.freebsd.org (Postfix) with ESMTP
	id 21AC437B503; Tue,  3 Oct 2000 12:16:09 -0700 (PDT)
Received: (from bright@localhost)
	by fw.wintelcom.net (8.10.0/8.10.0) id e93JG4a06283;
	Tue, 3 Oct 2000 12:16:04 -0700 (PDT)
Date: Tue, 3 Oct 2000 12:16:04 -0700
From: Alfred Perlstein <bright@wintelcom.net>
To: Chuck Paterson <cp@bsdi.com>
Cc: John Baldwin <jhb@FreeBSD.ORG>, arch@FreeBSD.ORG,
	John Polstra <jdp@polstra.com>, Daniel Eischen <eischen@vigrid.com>,
	Matt Dillon <dillon@earth.backplane.com>, Greg Lehey <grog@lemis.com>
Subject: Re: Mutexes and semaphores
Message-ID: <20001003121604.H27736@fw.wintelcom.net>
References: <XFMail.001003010402.jhb@FreeBSD.org> <200010031528.JAA10873@berserker.bsdi.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <200010031528.JAA10873@berserker.bsdi.com>; from cp@bsdi.com on Tue, Oct 03, 2000 at 09:28:39AM -0600
Sender: owner-freebsd-arch@FreeBSD.ORG
Precedence: bulk
X-Loop: FreeBSD.ORG

> On 27-Sep-00 Alfred Perlstein wrote:
> > Right now I can't even do getpid() properly because we don't have
> > read/write-barriers.
> 
> We do have these.  I have some helper functions I'll try to run by the
> new-bus list tonight.
> 

* Chuck Paterson <cp@bsdi.com> [001003 08:28] wrote:
> Why do yo need a barier for getpid()?
> A barrier really is not guaranteed to be sufficient
> for the
> 
> #if defined(COMPAT_43) || defined(COMPAT_SUNOS)
>         p->p_retval[1] = p->p_pptr->p_pid;
> #endif

From linux/kernel/timer.c:
(It assumes struct proc is in stable storage)

/*
 * This is not strictly SMP safe: p_opptr could change
 * from under us. However, rather than getting any lock
 * we can use an optimistic algorithm: get the parent
 * pid, and go back and check that the parent is still
 * the same. If it has changed (which is extremely unlikely
 * indeed), we just try again..
 *
 * NOTE! This depends on the fact that even if we _do_
 * get an old value of "parent", we can happily dereference
 * the pointer: we just can't necessarily trust the result
 * until we know that the parent pointer is valid.
 *
 * The "mb()" macro is a memory barrier - a synchronizing
 * event. It also makes sure that gcc doesn't optimize
 * away the necessary memory references.. The barrier doesn't
 * have to have all that strong semantics: on x86 we don't
 * really require a synchronizing instruction, for example.
 * The barrier is more important for code generation than
 * for any real memory ordering semantics (even if there is
 * a small window for a race, using the old pointer is
 * harmless for a while).
 */
asmlinkage long sys_getppid(void)
{
        int pid;
        struct task_struct * me = current;
        struct task_struct * parent;

        parent = me->p_opptr;
        for (;;) {
                pid = parent->pid;
#if CONFIG_SMP
{
                struct task_struct *old = parent;
                mb();
                parent = me->p_opptr;
                if (old != parent)
                        continue;
}
#endif
                break;
        }
        return pid;
}



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-arch" in the body of the message