On Wed, 8 Jun 2011, Peter Zijlstra wrote: > On Wed, 2011-06-08 at 22:52 +0200, Ingo Molnar wrote: > > Hm, i thought it would be possible to only express it via the > > slowpath: if mutex_trylock() succeeds then *all* execution goes into > > the slowpath so we don't have to take all the fastpaths into account. > > Right, but you first have to take wait_lock, then do the trylock, but > that's complicated for asm/mutex-null.h because trylock will then also > try to obtain the wait_lock. > > You can do it by creating ___mutex_trylock_slowpath() which contains the > meat of __mutex_trylock_slowpath() and then implement > atomic_mutex_trylock{_irq,_irqsave,} using that, not releasing wait_lock > on success. > > Shouldn't be too bad, but it ain't too pretty either. > > Furthermore, like I said in my initial patch, I share Thomas' worry > about 'creative' usage of these primitives. We are way better off with the semaphore abuse confined to printk.c. A mutex would give us lockdep coverage, but due to the strict owner semantics - which we have already proven in -rt by converting it to a mutex - we can annotate console_sem lockdep wise and still keep the nifty semaphore abuse. Further I don't have any worries about -rt either as a RT task using printf is doomed anyway and we should not encourage that by making it somehow more deterministic. Thanks, tglx -- To unsubscribe from this list: send the line "unsubscribe linux-tip-commits" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html