| 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 | Index | 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 <2012> 2013 2014 2015 2016 2017 2018 2019 2020 2021 2022 2023 2024 |
| <== Date ==> | <== Thread ==> |
|---|
| Subject: | Re: "spinlock" API |
| From: | Michael Davidsaver <[email protected]> |
| To: | Andrew Johnson <[email protected]> |
| Cc: | [email protected] |
| Date: | Fri, 08 Jun 2012 17:53:05 -0400 |
On 6/8/2012 3:48 PM, Andrew Johnson wrote:
Hi Michael, On 2012-06-07 Michael Davidsaver wrote:For the implementation of thread pool I would like to allow it to be used from interrupt context on RTEMS/vxworks. So it should need to use epicsInterruptLock(). I want to avoid using a global lock on Linux/Windows/etc. Now I could implement this internally for the thread pool only, but I thought I would float the possibility of creating a proper spin lock API. Initially RTEMS/vxworks would implement this using epicsInterrupt and the default implement would use epicsMutex.Have you looked at the epicsAtomicLock() and epicsAtomicUnlock() routines that Jeff uses in some of his epicsAtomic implementations?
It looks like the current posix implementation uses a global lock similar to epicsInterrupt. Do you see a way this could be avoided?
http://bazaar.launchpad.net/~epics-core/epics-base/3.15/view/head:/src/libCom/osi/os/posix/epicsAtomicOSD.cpp#L48
... but they do seem to be implementing the functionality you're after;
My goal for the thread pool implementation is to, as much as possible, allow two pools to function independently. Having a global mutex used in the queuing and dequeuing processes seems a likely point of contention.
This lock is not held when queued jobs are executed, but is taken by each worker thread after each job is executed. So it does see quite a bit of use.
Michael