On Fri, Sep 28, 2012 at 04:18:41PM +0530, Shantanu Gupta wrote: > Hello, > > I am currently studying mutex(es) and was referring to linux sources > for it's implementation. However I noticed one shortcoming, in > "/include/asm-generic/mutex-xchg.h" of the master branch inside > __mutex_fastpath_trylock, Why doesn't the kernel use a cmpxchg instead > of dirtying the value with xchg ? > > (The only thing that came to my mind was that x86_x64 implementation > mentioned that all x86_x64 cpu(s) have cmpxchg leading me to > assumption that certain archs can have xchg but not cmpxchg, so is it > this way just to work with architectures without a cmpxchg but with > xchg ?)
Yes. Btw, 'git annotate' helps with such questions-to-self sometimes. Because if you do $ git annotate include/asm-generic/mutex-xchg.h you can find the following patch adding __mutex_fastpath_trylock: commit 620a6fd185c084aa617c411f711533f01ea673c9 Author: Ingo Molnar <[email protected]> Date: Mon Jan 9 15:59:17 2006 -0800 [PATCH] mutex subsystem, add asm-generic/mutex-[dec|xchg|null].h implementations Add three (generic) mutex fastpath implementations. The mutex-xchg.h implementation is atomic_xchg() based, and should work fine on every architecture. The mutex-dec.h implementation is atomic_dec_return() based - this one too should work on every architecture, but might not perform the most optimally on architectures that have no atomic-dec/inc instructions. The mutex-null.h implementation forces all calls into the slowpath. This is used for mutex debugging, but it can also be used on platforms that do not want (or need) a fastpath at all. Signed-off-by: Ingo Molnar <[email protected]> Signed-off-by: Arjan van de Ven <[email protected]> HTH. -- Regards/Gruss, Boris. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
