[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC
Pär Björklund added the comment: The HLE variants were simply chosen to match the semantics on other platforms with regard to aquire/release. If Intel engineers say the plain versions are better that's good enough for me. It would be interesting seeing some benchmarks but I don't have any idea on how to reliably test the non happy path. On Thu, 14 Jun 2018, 21:32 Antoine Pitrou, wrote: > > Antoine Pitrou added the comment: > > I would be ok with reverting to the non-HLE variants. Does anyone want to > test the performance implications on TSX-enabled hardware? > > -- > > ___ > Python tracker > <https://bugs.python.org/issue30747> > ___ > -- ___ Python tracker <https://bugs.python.org/issue30747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC
Pär Björklund added the comment: My guess would be the cast from uintptr_t to intptr_t in the return type. I'll look into this, when possible, should have some time later this week or over the weekend. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC
Pär Björklund added the comment: Microsoft don't spend much time on the C compiler features, still lacking C99 features so I don't have much hope of getting C11 support anytime soon or at all. One could of course implement a cross platform stdatomic library that matches the C11 spec. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30687] build.bat should locate msbuild.exe rather than vcvarsall.bat
Pär Björklund added the comment: I don't believe that this is a bug in Visual Studio as MSBuild is used for .NET projects as well it should be available even without the C++ tooling installed. Checking for the targets file seems like a workable solution. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30687> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC
Pär Björklund added the comment: Antoine said it best. It's very hard to prove that this code is correct or incorrect as it requires multiple threads accessing the same variable and very specific timings to produce an actual issue. My PR only solved half of the issue because I didn't really have a good idea for how to handle the load macro but I think it out today so I'll be updating the PR. Would there be any interest of implementing them for MSVC/ARM as well? It's basically the same code so not much work, however I don't have a platform to actually test it. -- ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC
Changes by Pär Björklund <per.bjorkl...@gmail.com>: -- pull_requests: +2433 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30747] _Py_atomic_* not actually atomic on Windows with MSVC
New submission from Pär Björklund: _Py_atomic_store and _Py_atomic_load are not implemented as atomic operations on Windows when using Visual Studio to build. This might cause hard to troubleshoot behaviour, especially in third party hosting applications.. -- components: Interpreter Core messages: 296786 nosy: Paxxi priority: normal severity: normal status: open title: _Py_atomic_* not actually atomic on Windows with MSVC type: enhancement versions: Python 3.6, Python 3.7 ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30747> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30687] build.bat should locate msbuild.exe rather than vcvarsall.bat
Pär Björklund added the comment:
Currently I have VS2017 installed without C++ tooling for .NET development. The
C++ tooling breaks other projects I'm working on.
I have VS2015 Community update 3 installed with C++ tooling and the latest
compatible Windows SDK.
Before this patch everything builds as expected using PCBuild\build.bat -e.
After this patch it fails instantly with
Using "C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\\MSBuild\15.0\Bin\msbuild.exe" (found in the Visual
Studio 2017 registry)
C:\code\cpython>"C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\\MSBuild\15.0\Bin\msbuild.exe"
"C:\code\cpython\PCbuild\pcbuild.proj" /t:Build /m /nologo /v:m
/p:Configuration=Release /p:Platform=Win32 /p:IncludeExternals=true
/p:IncludeSSL=true /p:IncludeTkinter=true /p:UseTestMarker= /p:GIT="C:\Program
Files\Git\cmd\git.exe"
C:\code\cpython\PCbuild\pythoncore.vcxproj(42,3): error MSB4019: The imported
project "C:\Program Files (x86)\Microsoft Visual
Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.Cpp.Default.props"
was not found. Confirm that the p ath in the declaration is correct,
and that the file exists on disk.
Commenting out the following lines from find_msbuild.bat and everything is back
to working
@rem VS 2017 sets exactly one install as the "main" install, so we may find
MSBuild in there.
@reg query "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" /v 15.0
/reg:32 >nul 2>nul
@if NOT ERRORLEVEL 1 @for /F "tokens=1,2*" %%i in ('reg query
"HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\SxS\VS7" /v 15.0 /reg:32')
DO @(
@if "%%i"=="15.0" @if exist "%%k\MSBuild\15.0\Bin\msbuild.exe" @(set
MSBUILD="%%k\MSBuild\15.0\Bin\msbuild.exe")
)
@if exist %MSBUILD% (set _Py_MSBuild_Source=Visual Studio 2017 registry) & goto
:found
--
___
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue30687>
___
___
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
[issue30687] build.bat should locate msbuild.exe rather than vcvarsall.bat
Pär Björklund added the comment: This change causes build failures when VS2017 is installed without the C++ tooling as it finds MSBuild belonging to VS2017 but it can't build using it. Microsoft recommends using this tool https://github.com/microsoft/vswhere to find and set up the paths, it also works with VS2015. -- nosy: +Paxxi ___ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue30687> ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
