Switch to std::atomic?

[Rik]

jwe,

I have been looking at the performance of Octave and one of the slow points
has been the atomic operations.  This led me to look at the actual code in
oct-refcount.h quoted below.

#if (defined (OCTAVE_ENABLE_ATOMIC_REFCOUNT) \
     && (defined (__GNUC__) || defined (_MSC_VER)))

#  if defined (__GNUC__)

#    define OCTAVE_ATOMIC_INCREMENT(x) __sync_add_and_fetch (x,  1)
#    define OCTAVE_ATOMIC_DECREMENT(x) __sync_add_and_fetch (x, -1)
#    define OCTAVE_ATOMIC_POST_INCREMENT(x) __sync_fetch_and_add (x,  1)
#    define OCTAVE_ATOMIC_POST_DECREMENT(x) __sync_fetch_and_add (x, -1)

#  elif defined (_MSC_VER)

#    include <intrin.h>

#    define OCTAVE_ATOMIC_INCREMENT(x)                  \
  _InterlockedIncrement (static_cast<long *> (x))

#    define OCTAVE_ATOMIC_DECREMENT(x)                  \
  _InterlockedDecrement (static_cast<long *> (x))

#    define OCTAVE_ATOMIC_POST_INCREMENT(x)             \
  _InterlockedExchangeAdd (static_cast<long *> (x))

#    define OCTAVE_ATOMIC_POST_DECREMENT(x)             \
  _InterlockedExchangeAdd (static_cast<long *> (x))

#  endif

So, only with gcc (or something close to it like clang) or on Windows do we
have true atomic instructions.  If these conditions aren't met then
ordinary, non-atomic operations are substituted which won't work if
plotting or the GUI are used.

Would it make sense to switch to using std::atomic<octave_idx_type>?  In
that case, Octave would be portable to any machine with a valid C++ runtime
library, and we certainly require that.  The std::atomic class overloads
the (pre-, post-)(increment, decrement) operators so one could write more
readable code with count++ rather than OCTAVE_ATOMIC_POST_INCREMENT(count).

Just an idea, but I don't want to go ahead if there is some larger reason
we shouldn't do this.

--Rik