On Jul 23, 2012, at 10:24, Iain Sandoe wrote: >> This patch implements a check in the runtime library that determines whether >> the current target supports the atomic primitives up to 64 bits. > > If I understand the name of the flag, it looks like an "all or nothing" for > atomic primitives? > is that a consequence of the language definition, or simply that it isn't > worth spending a lot of effort on 32 bit machines?
There is nothing related to the language definition here, as these are not standardized packages, but part of the implementation. Attempts to use them directly from user programs will result in warnings. There are a few issues. We really don't want to have different versions of the spec for different targets. Rather, we'd have functions that either raise an exception or use a lock-based implementation if the target lacks the required capabilities. The system-specific boolean is a mostly a method that allows us to "switch off" our use of lock-free protected types on a per system basis. This avoids unnecessary instability in less commonly used platforms while we're enhancing this new capability. IIUC, all ports are supposed to implement the atomic built-ins. If they are not supported in hardware, there should be a library function for it that uses locking. The problem we're trying to address is builds failing because of undefined references to __atomic_* functions. I could also have used __atomic_always_lock_free, which is better in many ways, but we also need to know in the front end what expansion to use for protected types. My initial thought was to just have the front end build some trees calling __atomic_always_lock_free and see if they fold to True. However, this was considered undesirable. The alternative would be to have the front end call can_compare_and_swap_p(), but that would have the front end depend on rtl.h, which even I understand is bad. Probably can_compare_and_swap_p() should be moved to a better place, so the front end can use it directly. As I felt it was important to address the failures quickly, we used the current approach. -Geert
