Hi Kukee,
> Do you have any plan to work on the spin-lock?
> Actually, my parallel-callbacks for SMP requires the spin-lock.
I implemented the atomic library because I needed primitive
set/get/incr/decr features for smart pointer reference counting, and also
the compare-and-swap features are useful when I need to be certain that lazy
initialization is only done once.
I wasn?t thinking about implementing spin-locks because they are typically
provided by the OS as some kind of mutex primitive. It's certainly true that
we could implement portable spin locks now that we have portable atomics.
I seem to recall that, on windows, the fast in-process version of their
mutex primitive is a spin-lock hybrid (spin first and then fall back to
using the OS to block for lock release notification). I can guess that the
OS implementers might have some unique advantages over user level code for
implementing such hybrid approaches, but of course a user-land hybrid could
have some unique advantages also because it might completely avoid the
change mode to kernel system call overhead. Considering this further I
wouldn?t be shocked to discover that the windows critical section is
actually spinning in user-land and only changing mode to kernel after the
spin count decrements down to zero.
Nevertheless, it might be very interesting to run some benchmarks. I have a
lot on my plate so if you would like to look into this, that would be great!
Have a look at libCom/test/epicsAtomicPerform and libCom/test/epicsMutexTest
for some preexisting performance measurements.
Thanks and best regards,
Jeff
______________________________________________________
Jeffrey O. Hill Email [email protected]
LANL MS H820 Voice 505 665 1831
Los Alamos NM 87545 USA FAX 505 665 5107
Message content: TSPA
With sufficient thrust, pigs fly just fine. However, this is
not necessarily a good idea. It is hard to be sure where they
are going to land, and it could be dangerous sitting under them
as they fly overhead. -- RFC 1925
> -----Original Message-----
> From: Kim, Kukhee [mailto:[email protected]]
> Sent: Wednesday, August 31, 2011 2:14 PM
> To: [email protected]; [email protected]
> Cc: [email protected]; Williams Jr., Ernest L.; Rogind, Debbie
> Subject: Atomic operation library and spin-lock for the epics ring buffer
>
> Hi Jeff;
>
> I am watching your series of releases which are related with the atomic
> operation.
> I think, we are ready to work for the spin-lock issue on the epics ring
> buffer.
> Do you have any plan to work on the spin-lock?
> Actually, my parallel-callbacks for SMP requires the spin-lock.
>
> Please, let me know, if there is anything I can do.
>
> Thank you.
> Best regards,
> Kukhee
>
> --------------------------------------------
> Kukhee Kim
> SLAC National Accelerator Laboratory
> 2575 Sand Hill Rd, MS 64
> Menlo Park, CA 94025
> Email: [email protected]
> Phone: (650)926-4912
- Replies:
- RE: Atomic operation library and spin-lock for the epics ring buffer Williams Jr., Ernest L.
- Navigate by Date:
- Prev:
Re: [Merge] lp:~epics-core/epics-base/epicsR3.15-atomics into lp:epics-base Jeff Hill
- Next:
Re: [Merge] lp:~epics-core/epics-base/3.15-buildCompilerSpecific into lp:epics-base Andrew Johnson
- 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:
[Merge] lp:~johill-lanl/epics-base/epicsThreadOnce-atomics-based into lp:epics-base Jeff Hill
- Next:
RE: Atomic operation library and spin-lock for the epics ring buffer Williams Jr., Ernest L.
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
<2011>
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|