[Bf-committers] Different behavior of our atomic operation depending on compiler
montagne29 at wanadoo.fr
Wed Jul 1 12:39:56 CEST 2015
Ah yes indeed, thanks!
Also, now in the 'cas' case on OSX, we have this code:
uint64_t init_val = *v;
OSAtomicCompareAndSwap64((int64_t)old, (int64_t)_new, (int64_t *)v);
(because OSX has no primitive returning original value of 'v').
As far as I can see, this operation is no more strictly atomic:
* thread A sets its init_val
* thread B calls OSAtomicCompareAndSwap64() and change value of v
* thread A calls OSAtomicCompareAndSwap64() based on 'new' v value
* thread A returns invalid orginal value...
Probably not a crucial issue currently?
Le 01/07/2015 11:36, Brecht Van Lommel a écrit :
> "InterlockedExchangeAdd(p, x) + x" works exactly the same as"
> __sync_add_and_fetch(p, x)", no need to use asm.
> On Wed, Jul 1, 2015 at 9:53 AM, Bastien Montagne <montagne29 at wanadoo.fr> wrote:
>> So, trying to hunt an strange issue with Windows scons builds of
>> filebrowser work, I found that our attomic operations (defined in
>> intern/atomic/atomci_ops.h) do not return the same things on MSVC than
>> with other OS/compilers.
>> With GCC & co we use `__sync_add_and_fetch`, on OSX, `OSAtomicAdd64`,
>> with MSVC `InterlockedExchangeAdd64`, and have a fallback implementation
>> in plain assembler.
>> According to documentations (and my limited asm understanding), MSVC
>> version returns the value of `*p` *before* the operation, while all
>> others return it *after* the operation (i.e. return the result of the
>> I doubt this is desired behavior, and think it could easily generate
>> nasty bug some day… MSVC does not seem to have a 'return value after
>> operation' variant from quick look at the doc? Maybe we should just
>> remove the MSVC case completely and use asm version instead?
>> Bf-committers mailing list
>> Bf-committers at blender.org
> Bf-committers mailing list
> Bf-committers at blender.org
More information about the Bf-committers