[Bug 1932118] Re: Bug in vxWorks epicsAtomicCmpAndSwapIntT

[Dirk Zimoch via Core-talk <core-talk at aps.anl.gov>]

Here are the test results on vxWorks 6.7 ppc604

Before fix:
-> epicsAtomicTest
[...]
not ok  8 - compareAndSwap(Int, -34, -10)==-44
not ok  9 - compareAndSwap(Sizet, 34, 10)==40
not ok 10 - compareAndSwap(voidp, NULL, (void*)&Sizet)==(void*)&voidp
[...]
not ok 14 - compareAndSwap(Int, -44, -10)==-44
not ok 15 - compareAndSwap(Sizet, 40, 10)==40
not ok 16 - compareAndSwap(voidp, (void*)&voidp, (void*)&Sizet)==(void*)&voidp
[...]
    Results
    =======
       Tests: 50 
      Passed:  44 = 88.00%
      Failed:   6 = 12.00%

-> epicsAtomicPerform
# epicsAtomicSet of "i" takes 0.080311 microseconds
# epicsAtomicSet of "j" takes 0.080309 microseconds
# epicsAtomicSet of "Pv" takes 0.080330 microseconds
# raw incr of "i" and a NOOP function call takes 0.039048 microseconds
# raw incr of "j" and a NOOP function call takes 0.039061 microseconds
# epicsAtomicIncr "i" takes 0.074861 microseconds
# epicsAtomicIncr "j" takes 0.074872 microseconds
# epicsAtomicCmpAndSwap of "i" takes 0.077072 microseconds
# epicsAtomicCmpAndSwap of "j" takes 0.077066 microseconds
# epicsAtomicCmpAndSwap of "Pv" takes 0.077709 microseconds
# retOwnership() takes 0.148657 microseconds
# passRefOwnership() takes 0.291261 microseconds

After fix:
-> epicsAtomicTest
[...]
    Results
    =======
       Tests: 50 
      Passed:  50 = 100.00%

-> epicsAtomicPerform
# epicsAtomicSet of "i" takes 0.080310 microseconds
# epicsAtomicSet of "j" takes 0.080309 microseconds
# epicsAtomicSet of "Pv" takes 0.080331 microseconds
# raw incr of "i" and a NOOP function call takes 0.039049 microseconds
# raw incr of "j" and a NOOP function call takes 0.039061 microseconds
# epicsAtomicIncr "i" takes 0.075062 microseconds
# epicsAtomicIncr "j" takes 0.074873 microseconds
# epicsAtomicCmpAndSwap of "i" takes 0.035710 microseconds
# epicsAtomicCmpAndSwap of "j" takes 0.036103 microseconds
# epicsAtomicCmpAndSwap of "Pv" takes 0.034744 microseconds
# retOwnership() takes 0.148437 microseconds
# passRefOwnership() takes 0.291260 microseconds

That means, using EpicsAtomicLockKey is actually twice as fast as using vxCas!
So I was curious and compiled again using only the pre-6.6 implementation without vxAtomic*:

-> epicsAtomicPerform
# epicsAtomicSet of "i" takes 0.080327 microseconds
# epicsAtomicSet of "j" takes 0.080339 microseconds
# epicsAtomicSet of "Pv" takes 0.080339 microseconds
# raw incr of "i" and a NOOP function call takes 0.039070 microseconds
# raw incr of "j" and a NOOP function call takes 0.039071 microseconds
# epicsAtomicIncr "i" takes 0.034906 microseconds
# epicsAtomicIncr "j" takes 0.034893 microseconds
# epicsAtomicCmpAndSwap of "i" takes 0.036107 microseconds
# epicsAtomicCmpAndSwap of "j" takes 0.035703 microseconds
# epicsAtomicCmpAndSwap of "Pv" takes 0.034886 microseconds
# retOwnership() takes 0.092999 microseconds
# passRefOwnership() takes 0.179527 microseconds

Now epicsAtomicIncr is even faster than raw incr! Is there maybe
something wrong with the time measurement?

-- 
You received this bug notification because you are a member of EPICS
Core Developers, which is subscribed to EPICS Base.
Matching subscriptions: epics-core-list-subscription
https://bugs.launchpad.net/bugs/1932118

Title:
  Bug in vxWorks epicsAtomicCmpAndSwapIntT

Status in EPICS Base:
  Fix Committed

Bug description:
  The usage of epicsAtomicCmpAndSwapIntT() in callback.c suggests that
  the function should return the previous value. But the VxWorks
  implementation uses vxCas() which is documented as returning "TRUE if
  the write actually occurs, FALSE otherwise."

  vxAtomicLib.html:
  vxCas( )
  NAME
      vxCas( ) - atomically compare-and-swap the contents of a memory location 

  SYNOPSIS
      BOOL vxCas
          (
          atomic_t *  target,    
          atomicVal_t oldValue,  
          atomicVal_t newValue   
          )

  DESCRIPTION
      This routine performs an atomic compare-and-swap; testing that *target contains oldValue, and if it does, setting the value of *target to newValue.

  RETURNS
      TRUE if the swap is actually executed, FALSE otherwise.

  
  Comparing this with the gcc documentation:
  bool __sync_bool_compare_and_swap (type *ptr, type oldval type newval, ...)
  type __sync_val_compare_and_swap (type *ptr, type oldval type newval, ...)

  These builtins perform an atomic compare and swap.  That is, if the
  current value of *ptr is oldval, then write newval into *ptr.

  The “bool” version returns true if the comparison is successful and newval was written.
  The “val” version returns the contents of *ptr before the operation.

  
  That means epicsAtomicCmpAndSwapIntT() behaves behaves like __sync_bool_compare_and_swap(). Simply casting the return value from BOOL to the type of oldVal does not change that.

  But the usage implies an expected bahavior like
  __sync_val_compare_and_swap (), wich is used in the gcc implementation
  of epicsAtomicCmpAndSwapIntT().

  
  This bugs prevents the callback threads from being started in vxWorks 6.7, maybe more or all vxWorks 6 versions.

To manage notifications about this bug go to:
https://bugs.launchpad.net/epics-base/+bug/1932118/+subscriptions