On 18/05/16 17:18, Sergey Fedorov wrote: > On 18/05/16 03:28, Emilio G. Cota wrote: >> On Tue, May 17, 2016 at 23:20:11 +0300, Sergey Fedorov wrote: >>> On 17/05/16 23:04, Emilio G. Cota wrote: >> (snip) >>>> +/* >>>> + * We might we tempted to use __atomic_test_and_set with __ATOMIC_ACQUIRE; >>>> + * however, the documentation explicitly says that we should only pass >>>> + * a boolean to it, so we use __sync_lock_test_and_set, which doesn't >>>> + * have this limitation, and is documented to have acquire semantics. >>>> + */ >>>> +#define atomic_test_and_set_acquire(ptr) __sync_lock_test_and_set(ptr, >>>> true) >>> So you are going to stick to *legacy* built-ins? >> Why not? AFAIK the reason to avoid __sync primitives is that in most cases >> they include barriers that callers might not necessarily need; __atomic's >> allow for finer tuning, which is in general a good thing. However, >> __sync_test_and_set has the exact semantics we need, without the limitations >> documented for __atomic_test_and_set; so why not use it? > So it should be okay as long as the legacy build-ins are supported.
However, there's also __atomic_compare_exchange_n(). Could it be the choice? Kind regards, Sergey
