From owner-cvs-src@FreeBSD.ORG  Mon Jul  4 10:23:11 2005
Return-Path: <owner-cvs-src@FreeBSD.ORG>
X-Original-To: cvs-src@freebsd.org
Delivered-To: cvs-src@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id D1D2216A41C;
	Mon,  4 Jul 2005 10:23:11 +0000 (GMT)
	(envelope-from grehan@freebsd.org)
Received: from liberty.onthenet.com.au (liberty.OntheNet.com.au
	[203.22.124.10])
	by mx1.FreeBSD.org (Postfix) with ESMTP id 61FC643D48;
	Mon,  4 Jul 2005 10:23:11 +0000 (GMT)
	(envelope-from grehan@freebsd.org)
Received: from [203.144.2.137] (CPE-2-137.dsl.OntheNet.net [203.144.2.137])
	by liberty.onthenet.com.au (8.12.9 - 20030918/8.12.9) with ESMTP id
	j64ANA7v063172; Mon, 4 Jul 2005 20:23:10 +1000 (EST)
	(envelope-from grehan@freebsd.org)
Message-ID: <42C90E09.5000106@freebsd.org>
Date: Mon, 04 Jul 2005 20:23:05 +1000
From: Peter Grehan <grehan@freebsd.org>
User-Agent: Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.7.2) Gecko/20041016
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Robert Watson <rwatson@freebsd.org>
References: <200507022313.j62NDWYC028248@repoman.freebsd.org>
	<42C90419.8070509@freebsd.org>
	<20050704105721.Y2768@fledge.watson.org>
	<42C90A29.2030706@freebsd.org>
	<20050704111844.D2768@fledge.watson.org>
In-Reply-To: <20050704111844.D2768@fledge.watson.org>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Cc: cvs-src@freebsd.org, cvs-all@freebsd.org, src-committers@freebsd.org,
	Andrew Thompson <thompsa@freebsd.org>, Peter Grehan <grehan@freebsd.org>
Subject: Re: cvs commit: src/sys/amd64/include _types.h src/sys/i386/include
 _types.h src/sys/net if_bridge.c src/sys/netinet ip_var.h       
 src/sys/netinet6 ip6_var.h
X-BeenThere: cvs-src@freebsd.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: CVS commit messages for the src tree <cvs-src.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/cvs-src>
List-Post: <mailto:cvs-src@freebsd.org>
List-Help: <mailto:cvs-src-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/cvs-src>,
	<mailto:cvs-src-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Mon, 04 Jul 2005 10:23:12 -0000

>> I'd say certainly ! In fact, are there any architectures that could 
>> guarantee atomicity in this case ?
> 
> I'd guess not, but couldn't say for sure.  The reason it's of interest 
> is that there are a number of places in the kernel where the atomicity 
> of integer and pointer reads is assumed, or order to implement 
> optimistic concurrency or where there are tolerable races.  In general, 
> because our compiler works hard to ensure alignment, and because we try 
> to run on architectures that provide hard failure in the presence of an 
> alignment failure, we probably don't have incorrectness as a result of 
> non-atomic non-aligned reads, but it's something to be careful not to 
> introduce, and a case where "hard failure" architectures provide a 
> visible failure where "do it slowly and less atomically" architectures 
> may mask the problem.

  Yep, I think for those cases you can/should rely on compiler-aligned 
data structures. I don't know that it makes a lot of sense to assume 
atomicity with simple loads for general areas in memory that aren't 
guaranteed to be aligned.

  I don't see ppc as any different than non-i386 arches, or perhaps even 
that one too, for this case.

later,

Peter.