8000 ENH: add locking around initializing the argparse cache by ngoldbaum · Pull Request #26430 · numpy/numpy · GitHub
[go: up one dir, main page]
Skip to content

ENH: add locking around initializing the argparse cache #26430

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
wants to merge 3 commits into from
Closed

ENH: add locking around initializing the argparse cache #26430

Show file tree
Hide file tree
Changes from 1 commit
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
2961406
TST: add a test to check if the argparse cache is thread safe
ngoldbaum May 13, 2024
cc94991
NOGIL: lock initializing the argparse cache
ngoldbaum May 15, 2024
9a3b8cc
BLD: import libatomic linking code from scipy
ngoldbaum May 15, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Prev Previous commit
BLD: import libatomic linking code from scipy
  • Loading branch information
@ngoldbaum
ngoldbaum committed May 16, 2024
commit 9a3b8cccf6f7fe35941ef203325e711a2a7de0d6
2 changes: 1 addition & 1 deletion numpy/_core/meson.build
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -1217,7 +1217,7 @@ py.extension_module('_multiarray_umath',
'src/npymath',
'src/umath',
],
dependencies: [blas_dep],
dependencies: [blas_dep, atomic_dep],
link_with: [npymath_lib, multiarray_umath_mtargets.static_lib('_multiarray_umath_mtargets')] + highway_lib,
install: true,
subdir: 'numpy/_core',
Expand Down
37 changes: 37 additions & 0 deletions numpy/meson.build
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -214,6 +214,43 @@ else
lapack_dep = declare_dependency(dependencies: [lapack, blas_dep])
endif

# Determine whether it is necessary to link libatomic. This could be the case
# e.g. on 32-bit platforms when atomic operations are used on 64-bit types.
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

RISC-V with GCC is weird in that it supports 64-bit atomic ops without -latomic, but not 8-bit or 16-bit ops.

So in CPython we had to adjust the test to check for both 64-bit and 8-bit atomic operations:
https://github.com/python/cpython/blob/406ffb5293a8c9ca315bf63de1ee36a9b33f9aaf/configure.ac#L7417-L7422

If you are only using atomic_int then it might not matter.

# The check is copied from SciPy, who copied it from Mesa
# <https://www.mesa3d.org/>.
null_dep = dependency('', required : false)
atomic_dep = null_dep
code_non_lockfree = '''
#include <stdint.h>
int main() {
struct {
uint64_t *v;
} x;
return (int)__atomic_load_n(x.v, __ATOMIC_ACQUIRE) &
(int)__atomic_add_fetch(x.v, (uint64_t)1, __ATOMIC_ACQ_REL);
}
'''
if cc.get_id() != 'msvc'
if not cc.links(
code_non_lockfree,
name : 'Check atomic builtins without -latomic'
)
atomic_dep = cc.find_library('atomic', required: false)
if atomic_dep.found()
# We're not sure that with `-latomic` things will work for all compilers,
# so verify and only keep libatomic as a dependency if this works. It is
# possible the build will fail later otherwise - unclear under what
# circumstances (compilers, runtimes, etc.) exactly.
if not cc.links(
code_non_lockfree,
dependencies: atomic_dep,
name : 'Check atomic builtins with -latomic'
)
atomic_dep = null_dep
endif
endif
endif
endif

# Copy the main __init__.py|pxd files to the build dir (needed for Cython)
__init__py = fs.copyfile('__init__.py')
Expand Down
0