I punted on determinig what to do with alignment issues when
implementing atomics for 4.7. The time has come however to address what
is to be done. I've put together a wiki page and discussed its contents
with a few people to get this cut. Hopefully it seems reasonably sane. :-)
I've added a link to the page from the primary memory model page, and it
can be found here: http://gcc.gnu.org/wiki/Atomic/GCCMM/UnalignedPolicy
in a nutshell:
- gcc will provide an atomic type attribute (like const and volatile)
which will also cause any required alignment for a target to utilize its
lock free instructions. C11 atomic types will use this, as wil the
C++11 atomic template class. This could cause an ABI breakage between
4.7 and 4.8 C++11 on a few targets, but the C++11 ABI is still not
finalized, so this would be the time to get it right.
- When using memory in an atomic built-in function which does not have
this attribute, the __atomic_{is,always}_lock_free routines will check
the known alignment of object , and if this matches what is required,
lock free instructions will still be generated.
- Anything GCC emits other than calls into libatomic *cannot* use
locks. Calls into an OS for lock-free operations are permitted.
- libatomic is integrated into the build now, so any customizations
beyond the basic implementation of lockfree instruction sequences should
go there.
The main thing which seems contentious is a new configuration options
--disable-atomic-resize which turns off the ability of the 'atomic'
type attribute to resize the underlying type to achive a lock free
implementation. My theory was that if some port found memory to be more
important than the speed and would sacrifice lockfree sequences in
favour of locks utilziing less memory, this would provide an easy way to
do it.
Perhaps it is not needed... thoughts? Its a configuration option rather
than a compiler flag because it is a potential ABI breakage.
Any thoughts on the rest of it? brain farts or simplifications?
Andrew