Deprecating CHPL_ATOMICS=locks

[jabraham17]

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

[mppf]

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.

[jabraham17]

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.