[zeromq-dev] atomic ops
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)
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
Rendering Research Lead - Weta Digital
Phone: +64 4 909 6870 (x6870)
Mobile: +64 21 0764 862
More information about the zeromq-dev