On 29/06/17 12:14, Andrew Haley wrote: > 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. :-) I'd very much this was not done. I may be wrong, but I think it is easy and natural for people to grasp the idea that __atomic supersedes __sync, and so they simply forget about __sync. Adding new functionality to __sync, so it continues to live on and indeed offers functionality unavailable in __atomic, is confusing. I'd look instead to a new intrinsic in __atomic (which makes documentation clearer, as it's all in one place). Also, __sync is a pain - the API is much less pleasant than __atomic, with regard to memory models and built-in compiler barriers. Using __atomic is much easier, and as soon as you use anything from __sync, you then have other stuff to handle, which is otherwise handled inherently by __atomic.
