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

[Peter Grehan]

>> 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.