the new read/write semaphores in 2.3.30

Dimitris Michailidis (dimitris@cthulhu.engr.sgi.com)
Wed, 08 Dec 1999 13:07:20 -0800 (PST)


I've been reading through the reader/writer semaphore code in 2.3.30 and
noticed the following piece of code in down_write_failed_biased():

/* if the lock is currently unbiased, awaken the sleepers
* FIXME: this wakes up the readers early in a bit of a
* stampede -> bad!
*/
if (atomic_read(&sem->count) >= 0)
wake_up(&sem->wait);

If I understood the code right sem->count cannot be >0 at that point because
the writer that is executing that code has been granted the semaphore, so
this should trigger BUG(). OTOH, sem->count can be 0 and in that case we
should wake up at most one process on sem->wait. If we wake up several only
one of them will branch to one of the *failed_biased() functions and the
others will end up where they are right now, so no reason to wake them up.
Instead, these processes should be kicked in down_read_failed_biased() (in
fact we need to wake up all the readers and at most one writer there).

The way it is right now I don't see how we wake up all the waiting readers.
Suppose a writer has been granted the semaphore and is about to leave
down_write_failed_biased(), and that two readers are on sem->wait having
executed down_read_failed() (the count was <0 when they first arrived
because other readers had the lock at the time and the writer was sleeping).
The writer wakes up the readers, one of them goes to
down_read_failed_biased() and the other to down_read_failed(). When the
writer up()s it will wake up the biased reader, but who wakes up the other
one?

Is my reading of the code correct?

-- 
Dimitris Michailidis                    dimitris@engr.sgi.com

- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/