[zeromq-dev] atomic ops

Luca Fascione lukes at wetafx.co.nz
Wed Feb 8 23:49:35 CET 2012


FWIW, going from memory __sync_fetch_and_add (or maybe__sync_add_and_fetch)
   is improperly prototyped in ICC 11 (it returns void, oddly enough).
(and ICC defines __GNUC__ on linux x86 and x86_64)
L



On 08/02/12 17:34, john skaller wrote:
> I am looking at the atomic ops stuff, and I find this a bit suspicious,
> and also suboptimal:
>
> #elif (defined __i386__ || defined __x86_64__)&&  defined __GNUC__
> #define ZMQ_ATOMIC_COUNTER_X86
>
> ...
>
> #elif defined ZMQ_ATOMIC_COUNTER_X86
>              integer_t oldval = -decrement;
>              volatile integer_t *val =&value;
>              __asm__ volatile ("lock; xaddl %0,%1"
>                  : "=r" (oldval), "=m" (*val)
>                  : "0" (oldval), "m" (*val)
>                  : "cc", "memory");
>              return oldval != decrement;
>
>
> First, I surely wouldn't trust inline assembler, and I'm suspicious of
> "lock; xadd". This code also won't be selected except on x86 or x86_64.
>
> Wouldn't it be better to use this function:
>
> type __sync_fetch_and_add (type *ptr, type value, ...)
>
> which is guaranteed to work on all processors?
>
> I'd trust gcc to do the right thing a lot more than inline assembler.
> That function is always available if __GNUC__ is set, on recent
> enough implementations of gcc. The spec comes from gcc 4.1.2.
> [Presumably config can double check..]
>
> --
> john skaller
> skaller at users.sourceforge.net
>
>
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev

-- 
Luca Fascione
Rendering Research Lead - Weta Digital
Phone:  +64  4 909 6870 (x6870)
Mobile: +64 21 0764 862




More information about the zeromq-dev mailing list