RE: atomic operations in base

["Jeff Hill" <johill@lanl.gov>]

Hi Michael,

> I've adapted the atomic integer operations that Jeff has in the cvs-trunk
branch

I must admit to feelings of shock, amazement, disappointment, etc that you
would 
take some extra effort to remove my author line from the source file and
substitute 
Brookhaven copyright for LANL when openly deriving from my published work.

> It is now plain C (not C++) 

good idea, that was an oversight that it includes some c++ (presumably just
c++ comments)

> and a smaller set of primitives (Set, Fetch, Add, and Compare+Swap)

Some comments.
1) I do now depend on some basic primitives to implement what I am working
on (Fetch, Set, 
Increment, Decrement, TestAndSet ). The Increment/Decrement primitives are
slightly faster 
than an add primitive because one does not have to pass an argument. Perhaps
its 
negligible.
2) I actually have had some doubts about my initial approach. There is an
opaque type
AtomicWord which is OS dependent, and it isn't currently even set in
concrete if it is a signed 
or unsigned integer! The GNU approach is to use a signed word, but Solaris
uses an unsigned 
word. Its slightly harder to implement correctly but I would probably prefer
to have the
external interface based on a standard type such as size_t and force the OSD
implementation
to adapt to that (both size and sign or lack thereof). That will probably
make supporting 64 
bit systems slightly more complicated. I believe that your version maybe
consistently uses a signed 
integer, but also believe that it is currently implemented incorrectly on
Solaris. I know 
that epicsInterruptLock will not suffice on any SMP system, and furthermore
it's not probably 
a good idea to let the code build on SMP OS if the interrupted locked
version is in use.
3) I did also write a performance test see test/osiAtomicTest.cpp

Jeff
______________________________________________________
Jeffrey O. Hill           Email        johill@lanl.gov
LANL MS H820              Voice        505 665 1831
Los Alamos NM 87545 USA   FAX          505 665 5107

Message content: TSPA


> -----Original Message-----
> From: Davidsaver, Michael [mailto:mdavidsaver@bnl.gov]
> Sent: Wednesday, August 25, 2010 2:28 PM
> To: Andrew Johnson; Jeff Hill; Lange, Ralph; Chabot, Daron; Eric Norum;
> Till Straumann; Benjamin Franksen
> Subject: atomic operations in base
> 
> All,
> 
> I've adapted the atomic integer operations that Jeff has in the
> cvs-trunk branch.  It is now plain C (not C++) and has a smaller set of
> primitives (Set, Fetch, Add, and Compare+Swap).  I've also written a
> unit test which checks the behavior of the primitives, and includes a
> test with two threads incrementing one counter to attempt to verify the
> atomic behavior.  The unit test checks both the GCC4 optimized version
> (if available) and the OS specific default.
> 
> I would like to get this tested on vxWorks and a broader range of RTEMS
> targets.
> 
> https://code.launchpad.net/~mdavidsaver/epics-base/atomic
> 
> So far I have tested this with Linux and RTEMS.  On Linux (i686 SMP)
> the
> GCC optimized version runs the test ~10x faster than the mutex based
> default (0.5s vs. 7.0s).  However, on RTEMS (mvme3100) the situation is
> reversed (1.8s vs. 1.1s) with the GCC version being slow.  Of course
> this could just be a problem with my test.
> 
> The threaded test also performs the same operation on a non-atomic
> integer.  On the multi-core x86 Linux box this produces a fairly random
> number.  On RTEMS (single core PPC) it has the same result as the
> atomic
> integer.  Can anyone explain this?  Are there cases where I can omit
> the
> special handling for RTEMS and/or PPC?
> 
> My first application of this is to provide a low impact way to do
> statistics of the IOC.  Specifically to keep track of the number of
> disconnected CA links in real time.  This is necessary to make my
> fsmRecord a realistic way to do state machines.
> 
> 
> Thanks,
> Michael
> 
> 
> The following is the result for RTEMS-mvme3100
> 
> 
> ***** epicsAtomicTest *****
> 1..23
> # Implemented with : GCC
> # Size asserted to be >= 32-bit
> ok  1 - sizeof(atomicValue)>=4
> # Check static initializer
> ok  2 - v==42
> ok  3 - bad==42
> # Test negative values
> ok  4 - v==-5
> # Verify maximum value
> ok  5 - v==CountTo
> # Test compare and exchange
> ok  6 - !b
> ok  7 - v==CountTo
> ok  8 - !!b
> ok  9 - v==44
> # Test Add
> ok 10 - v==44
> ok 11 - v==45
> ok 12 - v==45
> ok 13 - v==55
> # Test Add (Negative values)
> ok 14 - v==55
> ok 15 - v==35
> ok 16 - v==35
> ok 17 - v==-15
> ok 18 - v==-15
> ok 19 - v==15
> # Reset before count down test
> ok 20 - v==CountTo
> ok 21 - bad==CountTo
> # Counting down from 2147483647, Expect 47 remaining
> # Thread subtracting 100 10737418 times
> # Thread subtracting 100 10737418 times
> # Finished in 1.840000 sec
> # Atomic 47 Non-Atomic 47
> ok 22 - v==Expect
> not ok 23 - bad!=Expect
> 
>     Results
>     =======
>        Tests: 23
>       Passed:  22 = 95.65%
>       Failed:   1 =  4.35%
> 
> ***** epicsAtomicFallbackTest *****
> 1..23
> # Implemented with : EPICSLOCK
> # Size asserted to be >= 32-bit
> ok  1 - sizeof(atomicValue)>=4
> # Check static initializer
> ok  2 - v==42
> ok  3 - bad==42
> # Test negative values
> ok  4 - v==-5
> # Verify maximum value
> ok  5 - v==CountTo
> # Test compare and exchange
> ok  6 - !b
> ok  7 - v==CountTo
> ok  8 - !!b
> ok  9 - v==44
> # Test Add
> ok 10 - v==44
> ok 11 - v==45
> ok 12 - v==45
> ok 13 - v==55
> # Test Add (Negative values)
> ok 14 - v==55
> ok 15 - v==35
> ok 16 - v==35
> ok 17 - v==-15
> ok 18 - v==-15
> ok 19 - v==15
> # Reset before count down test
> ok 20 - v==CountTo
> ok 21 - bad==CountTo
> # Counting down from 2147483647, Expect 47 remaining
> # Thread subtracting 100 10737418 times
> # Thread subtracting 100 10737418 times
> # Finished in 1.140000 sec
> # Atomic 47 Non-Atomic 47
> ok 22 - v==Expect
> not ok 23 - bad!=Expect
> 
>     Results
>     =======
>        Tests: 23
>       Passed:  22 = 95.65%
>       Failed:   1 =  4.35%