From owner-freebsd-smp  Sun Jul  1  5:55:25 2001
Delivered-To: freebsd-smp@freebsd.org
Received: from segfault.kiev.ua (segfault.kiev.ua [193.193.193.4])
	by hub.freebsd.org (Postfix) with ESMTP
	id 3AD8137B401; Sun,  1 Jul 2001 05:55:16 -0700 (PDT)
	(envelope-from netch@iv.nn.kiev.ua)
Received: (from uucp@localhost)
	by segfault.kiev.ua (8) with UUCP id PVB32996;
	Sun, 1 Jul 2001 15:54:46 +0300 (EEST)
	(envelope-from netch@iv.nn.kiev.ua)
Received: (from netch@localhost)
	by iv.nn.kiev.ua (8.11.4/8.11.4) id f61CnX801110;
	Sun, 1 Jul 2001 15:49:33 +0300 (EEST)
	(envelope-from netch)
Date: Sun, 1 Jul 2001 15:49:33 +0300
From: Valentin Nechayev <netch@iv.nn.kiev.ua>
To: "E.B. Dreger" <eddy+public+spam@noc.everquick.net>
Cc: Terry Lambert <tlambert2@mindspring.com>,
	Chris Costello <chris@calldei.com>, freebsd-smp@FreeBSD.ORG,
	freebsd-hackers@FreeBSD.ORG
Subject: Re: libc_r locking... why?
Message-ID: <20010701154933.B376@iv.nn.kiev.ua>
References: <3B3C3346.E5496485@mindspring.com> <Pine.LNX.4.20.0106291334350.7587-100000@www.everquick.net>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <Pine.LNX.4.20.0106291334350.7587-100000@www.everquick.net>; from eddy+public+spam@noc.everquick.net on Fri, Jun 29, 2001 at 03:19:47PM +0000
X-42: On
Sender: owner-freebsd-smp@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-smp.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-smp>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-smp>
X-Loop: FreeBSD.org

 Fri, Jun 29, 2001 at 15:19:47, eddy+public+spam (E.B. Dreger) wrote about "Re: libc_r locking... why?": 

> Running processes on multiple CPUs is one goal.
> 
> [ libc_r locks don't assert "lock", not MP-safe ]
> 
> So the "lock" prefix is the only way to enforce cache coherency?
> Do you have handy a good reference on IPIs, other than the kernel
> APIC code (and, of course, Google and NorthernLight searches)?

You say about i386 architecture, don't you? All current and former processors
has AFAIK strict write ordering, and cache coherency is provided for all data.
If lock is obtained, it means that all previous data is written successfully
and caches of other processors are notified for your changes.
Use locks and don't worry for cache coherency, it is already done.

> Good to know, but, I'm not using libc_r... I was looking at
> existing code to help me double-check mine as I go.  I'm
> synchronizing processes with a "giant lock" token that each
> process cooperatively passes to the next... to simplify:

Did you check your code with some proven to be working between processes,
e.g. SysV IPC semaphores?


/netch

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