Messages in this thread | | | Date | Wed, 21 Dec 2005 20:51:20 +0300 | From | Oleg Nesterov <> | Subject | Re: [patch 05/15] Generic Mutex Subsystem, mutex-core.patch |
| |
Ingo Molnar wrote: > > * Oleg Nesterov <oleg@tv-sign.ru> wrote: > > > > + spin_lock(&lock->wait_lock); > > > + __add_waiter(lock, waiter, ti, task __IP__); > > > + set_task_state(task, task_state); > > > > I can't understand why __mutex_lock_common() does xchg() after adding > > the waiter to the ->wait_list. We are holding ->wait_lock, we can't > > race with __mutex_unlock_nonatomic() - it calls wake_up() and sets > > ->count under this spinlock. > > we must make sure that the drop has not been dropped meanwhile, on the > way in, between the fastpath-unlock atomic op, and the xchg() here.
Sorry for noise, probably I should just re-read your explanation tomorrow after some sleeping...
But why we can't add the waiter to ->wait_list _after_ xchg() ? What makes the difference? Fastpath atomic op can happen before or after xchg(), this is ok. Unlock path will look at ->wait_list only after taking spinlock, at this time we already added this waiter to the ->wait_list.
In other words: we are holding ->wait_lock, nobody can even look at ->wait_list. We can add the waiter to ->wait_list before or after atomic_xchg() - it does not matter.
Again no?
Oleg. - 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/
| |