Thanks for your pull request. It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA).

📝 Please visit https://cla.developers.google.com/ to sign.

Once you've signed, please reply here (e.g. I signed it!) and we'll verify. Thanks.

• If you've already signed a CLA, it's possible we don't have your GitHub username or you're using a different email address. Check your existing CLA data and verify that your email is set on your git commits.
• If you signed the CLA as a corporation, please let us know the company's name.

I signed it!

CLAs look good, thanks!

tACK

Compiled and confirmed there were no errors. All tests passed, and the benchmarks (static and shared) seemed reasonable at a glance. Didn't benchmark vis-à-vis my fix (#422). sipa's fix, after thinking about it, seems preferable to mine, although I'll leave mine open in case the team thinks otherwise.

Thank you very much for your contribution!

The comment at the top of atomic-pointer.h states "Also, some implementations are much slower than a memory-barrier based implementation (~16ns for based acquire-load vs. ~1ns for a barrier based acquire-load)."

While I'm not sure this toolchain issue is relevant anymore, we'd need to do some testing to confirm. Do you happen to have access to the platforms that have MemoryBarrier implementations? If it turns out that std::atomic implementations in modern toolchains are good enough, we can remove the MemoryBarrier code altogether, because we'll require C++11 soon.

@googlebot rescan

A Googler has manually verified that the CLAs look good.

(Googler, please make sure the reason for overriding the CLA status is clearly documented in these comments.)

ℹ️ Googlers: Go here for more info.

We removed AtomicPointer a while back. The codebase uses std::atomic directly now.