@Paxxi, thanks for your PR! By analyzing the history of the files in this pull request, we identified @jyasskin, @benjaminp and @akheron to be potential reviewers.

Hello, and thanks for your contribution!

I'm a bot set up to make sure that the project can legally accept your contribution by verifying you have signed the PSF contributor agreement (CLA).

Unfortunately our records indicate you have not signed the CLA. For legal reasons we need you to sign this before we can look at your contribution. Please follow the steps outlined in the CPython devguide to rectify this issue.

Thanks again to your contribution and we look forward to looking at it!

It seems you broke the build on Unix:
https://travis-ci.org/python/cpython/jobs/246629729#L1145

Parser/myreadline.c:311:33: error: implicit declaration of function '_Py_atomic_load_relaxed' is invalid in C99 [-Werror,-Wimplicit-function-declaration]
    if (_PyOS_ReadlineTState == PyThreadState_GET()) {
                                ^
./Include/pystate.h:252:31: note: expanded from macro 'PyThreadState_GET'
             ((PyThreadState*)_Py_atomic_load_relaxed(&_PyThreadState_Current))
                              ^

This should be ready now. Test suite passes for x86/x64, completely untested for ARM as I don't have any suitable environment.

I don't really know how to validate that they're correctly atomic. The operations aren't really suitable to implement a ref count or a mutex as a test case so I'm open to ideas of any way to test this.

I don't really know how to validate that they're correctly atomic.

I don't think we need to. The potential issues here are extreme edge case race conditions that may happen once a month on heavily-loaded production systems. There's little we can check for in the test suite, IMHO.

Longer term, one possibility would be to build Python with thread sanitizer. That's not compatible with MSVC AFAIK, though.

@Paxxi, partially related, but have you seen PR #2417 and do you have any opinion about it?

@zooba, do you think you can get some expert at Microsoft to take a look at this?
Otherwise, while I can't vouch for the correctness, this can't be worse than the statu quo, as long as it compiles fine :-)

Added comment about interlocked functions and removed the fence macros as they're not used.

@zooba, do you want to review this pre-merge or should it go ahead?

I think this is ready to merge. Would you like to add a NEWS entry using the "blurb" utility?

I'm not much of a writer so I'd rather skip writing anything about it. Feel free to do it on my behalf if it's considered newsworthy enough.

Well, I'm not sure how to edit your branch, perhaps you can try applying the following patch to it:

$ git diff --cached 
diff --git a/Misc/NEWS.d/next/Core and Builtins/2017-08-08-12-00-29.bpo-30747.g2kZRT.rst b/Misc/NEWS.d/next/Core and Builtins/2017-08-08-12-00-29.bpo-30747.g2kZRT.rst
new file mode 100644
index 0000000000..04a726a7e6
--- /dev/null
+++ b/Misc/NEWS.d/next/Core and Builtins/2017-08-08-12-00-29.bpo-30747.g2kZRT.rst       
@@ -0,0 +1,2 @@
+Add a non-dummy implementation of _Py_atomic_store and _Py_atomic_load on
+MSVC.

Thanks! I added it to the commit now.

Default settings on Github afaik is that repo owners can push directly to a contributors branch for a PR but I didn't know it needed to be part of the commit.

Should be all set now.

Ok, thank you!