On 29/06/17 10:40, Alexander Monakov wrote: > On Thu, 29 Jun 2017, Andrew Haley wrote: >> I think I now properly understand Richard Earnshaw's point: that we >> *do* support a full set of atomic primitives for 16-byte types via >> libatomic, but for them to work as a sequentially-consistent set we >> must use the same locking scheme for all of them. It's ugly, and >> horrible for anyone who simply wants a double-word CAS, but it is what >> it is. We can't use LDXP because it isn't atomic on its own, and the >> ARM manual is quite explicit about this. Anyone who wants to use >> a real compare-and-swap-16 is on their own. > > Note that there's no 'atomic read' primitive among __sync builtins, so > IMO it gives a way out: expose native doubleword cas via __sync_compare_and_swap, > use a locking scheme for its __atomic counterpart. So it does. Good idea. Although documenting the incompatibility between __atomic and __sync might be rather problematic. :-) -- Andrew Haley Java Platform Lead Engineer Red Hat UK Ltd. <https://www.redhat.com> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
