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]

Potentially merging cxx-mem-model with mainline.

I'd like to have the cxx-mem-model branch considered for merging with mainline before we end stage 1 for GCC 4.7.

What it is

GCC has had the __sync built-ins for atomic operations for a number of years now. They implement a "sequential consistent" (AKA seq-cst) synchronization model which is the most restrictive (ie expensive) form of synchronization. It requires that all processes can see a consistent value for other shared memory variables at the point of the atomic operation. The new C++ standard defines other less restrictive modes which many newer architecture can make use of for improved performance in multi-threaded environments. These will also allow the optimizer more freedom in moving code around as well.

This branch has developed a new set of atomic built-ins which include a memory model parameter and meet the atomic requirements of C++11.

During development, I've kept a wiki page pretty updates about what its all about, rooted here:

What it involves

The new __atomic prefixed built-ins have been implemented with ease of target migration and maintenance in mind:

- The __atomic expanders first look for a new __atomic RTL pattern and use that if present.
- failing that, they fall back to using the original __sync implementation and patterns. This is less efficient if the memory model specified isn't seq-cst, but is correct in functionality. This also means all the __atomic built-ins work correctly today if a target has __sync support.

The original __sync builtins now invoke the __atomic expanders with the seq-cst memory model. This means that if a target has not been migrated to the new __atomic patterns, the __sync functions behave exactly as they do today (since __atomic expanders fall back to the original __sync patterns). When a target does specify new __atomic RTL patterns, the legacy __sync routines will automatically start using those patterns.

This means that a target does not need to support both __atomic and __sync patterns. Migrating involves simply renaming the __sync patterns and modifying them to deal with the memory model parameter.

There are new generic __atomic routines which provide support for arbitrary sized objects. Whenever possible, atomic operations are mapped to lock-free instruction sequences. This is not always possible either due to target restrictions, or oddly/large sized objects.

The __atomic builtins leave external function calls for these cases, but they target a well defined library interface documented here: I expect to spin off a small side project to implement this library in the next few months so that a library is easily available to resolve these calls.

With a few C++ template changes to utilize these new built-ins, libstdc++-v3 should have a fully functional implementation of atomics for this release.

What it doesn't do

It does not address other missing aspects of the c++ memory model. In particular, bitfields are still not compliant with not introducing new potential data races.

There are flags for load and store data races in mainline already, and some work has gone into limiting store data races, but testing is by no means thorough.

Whats left
Functionality is pretty much complete, but there are a few minor lose ends still to deal with. They could be done after a merge, in the next stage, or required before... you tell me :-)

- potentially implement -f[no]-inline-atomics (to never produce inline code and always call the library) and -f[no]-atomic-compare-swap-loop (To not fall back to a compare_and_swap loop to implement missing functionality)

- unaligned objects have undefined behaviour at the moment. Behaviour could be defined and add alignment checks and a parameter to __atomic_is_lock_free() for alignment checking purposes. Anything which doesn't map to one of the properly aligned 5 sized built-ins gets a library call.

- A bit of C++ template restructuring in the include files to remove the old fall back locked implementation and fully use the new __atomic builtins. (*in progress now*)

- Change external library calls for __atomic_op_fetch routines. (*patch submitted already*)

- There are a bunch of new tests that have been developed along the way, but I I expect to spend the next 2 months writing more detailed and specific runtime and compile time tests. And of course, fixing any of the fall out from those tests.

- There have been no new __atomic RTL patterns created. I was thinking about leaving this until the next release, but I suppose we could migrate a couple of the more popular targets

The final word
So what is the opinion/consensus on merging the branch? It would be nice to get this infrastructure in place for this release so we can get people to start using it, and then we can work out any issues that arise.

I'd have Aldy do the actual merge because if I do something will go amok for sure. I wont be around this weekend to fix any fallout, but I am around until Friday evening. I'm around all next week. I don't anticipate much problem since this is all new functionality for the most part, and mainline was merged with the branch a week or two ago.


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