Date: Mon, 4 Jul 2005 11:20:52 +0100 (BST) From: Robert Watson <rwatson@FreeBSD.org> To: Peter Grehan <grehan@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, cvs-all@freebsd.org, Andrew Thompson <thompsa@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 Message-ID: <20050704111844.D2768@fledge.watson.org> In-Reply-To: <42C90A29.2030706@freebsd.org> References: <200507022313.j62NDWYC028248@repoman.freebsd.org> <42C90419.8070509@freebsd.org> <20050704105721.Y2768@fledge.watson.org> <42C90A29.2030706@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 4 Jul 2005, Peter Grehan wrote: >>> FYI, any modern ppc implementation doesn't require strict alignment for >>> integer load/stores though there's a performance penalty for having to >>> split the access into smaller ones. >> >> While it's not immediately relevant to the IP code, generally speaking, >> is it the case that non-aligned integer reads can be non-atomic with >> respect to other CPUs due to the multiple access implementation? > > 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. Robert N M Watson
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20050704111844.D2768>