The usage of epicsAtomicCmpAndSwapIntT for example 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." (at least in VxWorks 6.7).
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.
So it seems epicsAtomicCmpAndSwapIntT is expected to behave like __sync_val_compare_and_swap (and that is what is
actually implemented in libcom/src/osi/compiler/gcc/epicsAtomicCD.h) but vxCas as used in
libcom/src/osi/os/vxWorks/epicsAtomicOSD.h actually behaves like __sync_bool_compare_and_swap.
Dirk
- Navigate by Date:
- Prev:
Re: Deadlock on VxWorks 6.7 Zimoch Dirk (PSI) via Core-talk
- Next:
softiIoc and softIocPVA incomplete on VxWorks (and others?) Zimoch Dirk (PSI) via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: Tests on RTEMS-pc686-qemu Chandler, Brendan via Core-talk
- Next:
softiIoc and softIocPVA incomplete on VxWorks (and others?) Zimoch Dirk (PSI) via Core-talk
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
<2021>
2022
2023
2024
|