Date: Mon, 04 Jul 2005 20:23:05 +1000 From: Peter Grehan <grehan@freebsd.org> To: Robert Watson <rwatson@freebsd.org> 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 Message-ID: <42C90E09.5000106@freebsd.org> In-Reply-To: <20050704111844.D2768@fledge.watson.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>
next in thread | previous in thread | raw e-mail | index | archive | help
>> 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.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?42C90E09.5000106>