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: | [email protected] |
Date: | Tue, 12 Jun 2012 10:13:31 -0400 |
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 ofmutexes, 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 actof taking or releasing a mutex always requires a context switch, whereas anatomic 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