Messages in this thread |  | | Date | Fri, 30 Aug 2002 10:19:02 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: [patch] scheduler fixes, 2.5.32-BK |
| |
On Fri, 30 Aug 2002, Ingo Molnar wrote: > > it touches the waitqueue spinlock - and the __down() path [ie. the process > that gets woken up, which has the semaphore on the stack] takes the > spinlock after waking up. Ie. there's guaranteed synchronization, the > semaphore will not be 'unused' before the __down() path takes the spinlock > - ie. after the __up() path releases the spinlock. What am i missing?
So why couldn't this happen? This is what used to happen before, I don't see that consolidating the spinlock had any impact at all.
CPU #0 CPU #1
down() up()
lock decl (negative) __down() lock incl spinlock() __up() atomic_add_negative() success - break spinunlock(); } wake_up() return - semaphore is now invalid spin_lock()
BOOM!
The fact is, that as long as down() and up() avoid taking the spinlock _before_ they touch "count", they aren't synchronized.
And we definitely do _not_ want to take the spinlock before we touch count, since that would make the fast path a lot slower.
What?
Linus
- 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/
|  |