Experimental Physics and
Industrial Control System

Andrew Johnson via Core-talk <core-talk at aps.anl.gov> · Fri, 18 Jun 2021 16:51:29 -0000

@Dirk The VxWorks *TestHarness.munch files provide entry points for
running each test program individually, and one "epicsRun*Tests()" that
runs all the tests in a known working order and shows a summary of any
failures at the end. In most cases you need to mount the disk containing
the source code (preferably over NFS although netDrv mounts should work
too) and cd into the O.<target> directory where the .munch file was
built before you can run any test program.

For the libCom tests though you don't actually have to mount the source
disk because they don't need to load any .dbd or .db files like the
others do, but you should cd to a directory which VxWorks can write into
to allow epicsStdioTest() to create a file and read it back (if you
forget that cd it should just skip those tests). The final test in
epicsRunLibComTests() checks epicsAtExit() functionality and doesn't
really work properly with the test harness, so I display the summary
results from all the other tests before calling that; don't worry if it
hangs, I get that too and it would be a pain to fix it (we could drop
running it).

It seems a shame to replace a truly atomic operation (which uses the lwarx + stwcx. instructions on the PowerPC so it should be fast) with a slower one that has to lock out interrupts to achieve atomicity. It would be nice to compare the output from epicsAtomicPerform() before and after applying this fix to see what effect it has. Performance tests are not run by epicsRunLibComTests() but that test is included in the libComTestHarness.munch file so you could run it by hand.

I looked through the source code for the vxAtomic library yesterday but
it provides no routine with which we could directly implement the
epicsAtomicCmpAndSwapXxx() semantics that our API requires, although it
should be trivial to implement a __sync_bool_compare_and_swap()
equivalent from a __sync_val_compare_and_swap() routine. Our internal
uses could easily be converted to a new API that returns bool, and I see
no reason not to switch to that, although it's too late now to develop
that kind of change for the 7.0.6 release. It's getting a bit late to
even apply this patch, but I trust Dirk to have tested it sufficiently
that I'm going to anyway.

-- 
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:
  In Progress

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

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System