chapel icon indicating copy to clipboard operation
chapel copied to clipboard

Deprecating `CHPL_ATOMICS=locks`

Open jabraham17 opened this issue 1 year ago • 2 comments

The Chapel runtime currently maintains 3 different memory layers (CHPL_ATOMICS)cstdlib, intrinsics, and locks. cstdlib is the preferred and default option in most situations, while intrinsics and locks are both portability options for when the backend does not support C11 atomics. In nearly all cases, using intrinsics is the better portability option. The 2 exceptions that I know of are when using the PGI compiler and when using raspberry pi (specifically 32-bit raspberry pi). intrinsics is also usually more performant than locks.

Do we still need to support locks? We do have 2 distinct cases where locks is the only viable option, but recent testing has shown significant issues with locks. What can we do to other existing layers to maintain support for these platforms while still getting rid of locks

jabraham17 avatar Aug 14 '24 21:08 jabraham17

The 2 exceptions that I know of are when using the PGI compiler and when using raspberry pi (specifically 32-bit raspberry pi).

What are the specific issues here? I'd bet that the PGI compiler issue has been resolved in newer releases, but maybe we don't need PGI compiler support. I don't know what the issue is wit raspberry pi though.

mppf avatar Aug 15 '24 14:08 mppf

I'm not sure, its possible both of these issue have been resolved in newer releases. The PGI issue is noted in a comment in chpl_atomics.py, but I don't know if we have any testing with the PGI compiler. The raspberry pi issue is from our docs, which explicitly says to use locks.

jabraham17 avatar Aug 15 '24 15:08 jabraham17