EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
<== Date ==> <== Thread ==>

Subject: [Bug 1932118] Re: Bug in vxWorks epicsAtomicCmpAndSwapIntT
From: mdavidsaver via Core-talk <core-talk at aps.anl.gov>
To: core-talk at aps.anl.gov
Date: Thu, 24 Jun 2021 15:51:20 -0000
The __sync_synchronize() builtin expands on all (including -march=i386)
except arm-linux-gnueabi-cpp w/ the default march (appears to be
'-march=armv5te').

-- 
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

References:
[Bug 1932118] [NEW] Bug in vxWorks epicsAtomicCmpAndSwapIntT Dirk Zimoch via Core-talk

Navigate by Date:
Prev: Re: Problem building ezcaIDL on Windows Mark Rivers via Core-talk
Next: [Bug 1932118] Re: Bug in vxWorks epicsAtomicCmpAndSwapIntT mdavidsaver via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
Navigate by Thread:
Prev: [Bug 1932118] Re: Bug in vxWorks epicsAtomicCmpAndSwapIntT mdavidsaver via Core-talk
Next: [Bug 1932118] Re: Bug in vxWorks epicsAtomicCmpAndSwapIntT mdavidsaver via Core-talk
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  <20212022  2023  2024 
ANJ, 24 Jun 2021 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·