Messages in this thread | | | Date | Wed, 04 Nov 2009 18:19:35 +0100 | From | Eric Dumazet <> | Subject | Re: [RFC,PATCH] mutex: mutex_is_owner() helper |
| |
Ingo Molnar a écrit :
> To make sure this does not extend mutexes to be used a recursive > mutexes, mind naming it more clearly, like debug_mutex_is_owned(), and > adding a comment that says that this shouldnt be taken? > > Also, it's somewhat imprecise: on !SMP && !DEBUG_MUTEXES we might return > a false '1'. Which happens to work for the rtnl usecase - but might not > in other cases. >
Sure, we can chose another name, but what do you mean by a false '1' ?
1 means mutex is locked and that we could not check ownership. (best effort, ie same imprecise result than mutex_is_locked())
BTW, I was thinking of a mutex_yield() implementation, but could not cook it without hard thinking, maybe you already have some nice implementation ?
We have some uses of "mutex_unlock();mutex_lock();" things that are not working nicely because current thread immediately takes again mutex.
a true mutex_yield() would force current thread to go at the end of wait_list.
int mutex_yield(struct mutex *lock) { unsigned long flags;
// OK to test list without locking if (list_empty(&lock->wait_list)) return 0;
spin_lock_mutex(&lock->wait_lock, flags); if (!list_empty(&lock->wait_list)) { atomic_xchg(&lock->count, 1);// free mutex list_add_tail(&waiter.list, &lock->wait_list);//insert me at tail of wait_list wake head of wait_list __mutex_lock_common_condadd(mutex, TASK_UNINTERRUPTIBLE, DONT_ADD_TAIL, ...); } else { spin_unlock_mutex(&lock->wait_lock, flags); } return 1; }
Or maybe we should try something less complex (slowpath anyway)
int mutex_yield(struct mutex *lock) { int ret = 0;
if (mutex_needbreak(lock) || should_resched()) { mutex_unlock(lock); __cond_resched(); mutex_lock(lock); ret = 1; } return ret; }
Thanks -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |