On 6/11/2012 5:16 PM, Andrew Johnson wrote:
...
Can we design the default implementation to use atomic variables instead of
mutexes, unless there really is no alternative?
To be honest, I'm a little unsure what the performance implications of a
spinlock implementation would be when task preemption can't be disabled.
On a workstation OS the act
of taking or releasing a mutex always requires a context switch, whereas an
atomic operation does not.
Is this true? I thought that a syscall was required, but that the full
context switch only occurs if the lock is contested.
http://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/pthread_mutex_lock.c#l44
Spin-lock operations are supposed to be lighter
than a mutex ones on SMP, and that aspect of your suggestion is bothering me.
Maybe this should be called something other than "spinlock"?
What I want is something which allows for granular locking and is safe
to use from an ISR (when applicable). A spin lock is the only primitive
I know of which can do this in a RT or kernel environment. Outside of
this environment I don't care if it sleeps or not (I can't prevent this
anyway).
I'm also depending on the recursive behavior of both epicsMutex and
epicsInterruptLock.
Does this seem like an unusual use case?
Michael
- Replies:
- Re: "spinlock" API Michael Davidsaver
- References:
- "spinlock" API Michael Davidsaver
- Re: "spinlock" API Andrew Johnson
- Re: "spinlock" API Michael Davidsaver
- Re: "spinlock" API Andrew Johnson
- Navigate by Date:
- Prev:
Re: "spinlock" API Andrew Johnson
- Next:
Re: "spinlock" API Michael Davidsaver
- 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: "spinlock" API Andrew Johnson
- Next:
Re: "spinlock" API Michael Davidsaver
- Index:
2002
2003
2004
2005
2006
2007
2008
2009
2010
2011
<2012>
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|