On 6/11/2012 6:31 PM, Michael Davidsaver wrote:
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.
Just to be clear, I'm thinking of starvation issues like priority
inversion which can arise when the OS scheduler does not "know" about
the locking.
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
It seems that glibc can actually avoid a syscall in some cases. This is
implemented with an atomic test operation.
http://sourceware.org/git/?p=glibc.git;a=blob;f=nptl/lowlevellock.h
Michael
- Replies:
- Re: "spinlock" API Andrew Johnson
- References:
- "spinlock" API Michael Davidsaver
- Re: "spinlock" API Andrew Johnson
- Re: "spinlock" API Michael Davidsaver
- Re: "spinlock" API Andrew Johnson
- Re: "spinlock" API Michael Davidsaver
- Navigate by Date:
- Prev:
Re: "spinlock" API Michael Davidsaver
- Next:
Re: "spinlock" API 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:
Re: "spinlock" API Michael Davidsaver
- Next:
Re: "spinlock" API 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
|