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
grehan at freebsd.org
Mon Jul 4 10:23:12 GMT 2005
>> 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.
More information about the cvs-all