![]() | |||||||||||||
Messages in this thread |
On Tue, Jan 10, 2006 at 09:03:07PM +0300, Oleg Nesterov wrote: > Balbir Singh wrote: > > > > On Wed, Dec 21, 2005 at 07:42:14PM +0300, Oleg Nesterov wrote: > > > > > > Note that subsequent up() will not call wakeup(): ->count == 0, > > > it just increment it. That is why we are waking the next waiter > > > in advance. When it gets cpu, it will decrement ->count by 1, > > > because ->sleepers == 0. If up() (++->count) was already called, > > > it takes semaphore. If not - goes to sleep again. > > > > > > Or my understanding is completely broken? > > > > [ ... long snip ... ] > > > > The question now remains as to why we have the atomic_add_negative()? Why do > > we change the count in __down(), when down() has already decremented it > > for us? > > ... and why __down() always sets ->sleepers = 0 on return. > I think sem->sleepers initially started as a counter, but was later converted to a boolean value (0 or 1). The only possible values of sem->sleepers is 0, 1 or 2 and we always use sem->sleepers - 1 and set the value to either 0 or 1. sem->sleepers is set to 0, so that when the double wakeup is called on the wait queue, the task that wakes up (P2) corrects the count to (sem->sleepers - 1) = -1. This ensures that other tasks do not acquire the semaphore with down() (count is -1) and P2 sets sem->sleepers back to 1 and sleeps. > I don't have an answer, only a wild guess. > > Note that if P1 releases this semaphore before pre-woken P2 actually > gets cpu what happens is: > > P1->up() just increments ->count, no wake_up() (fastpath) > > P2 takes the semaphore without schedule. > > So *may be* it was designed this way as some form of optimization, > in this scenario P2 has some chances to run with sem held earlier. > P1->up() will do a wake_up() only if count < 0. For no wake_up() the count >=0 before the increment. This means that there is no one sleeping on the semaphore. Feel free to correct me, Balbir - 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/ | ||||||||||||
| Last update: 2006-01-11 06:35 [from the cache] ©2003-2008 | |||||||||||||