This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Dealing with alignment on atomic operations.

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:

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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]