Re: Read/write locks

H. Peter Anvin (hpa@transmeta.com)
21 Sep 1997 08:46:14 GMT

Followup to: <199709210759.DAA29661@jenolan.rutgers.edu>
By author: "David S. Miller" <davem@jenolan.rutgers.edu>
In newsgroup: linux.dev.kernel
> Adding this special "upgrader" state, and the new locking that goes
> with it, is unnecessary and in fact bloat if you think about the
> approach I am presenting.
>
> Consider the case where multiple code streams want to become readers
> with the "intension of writing" (updaters), but all of them will find
> what they want to update, not even there, and just drop the lock and
> leave.
>
> In the upgrader approach, here everyone would be stymied and walk into
> the critical section in lock-step. In my suggested scheme they'd all
> walk in in parallel and be on with it.
>

I think the point of the Upgrader state is that it *guarantees* that
the upgrade to a Writer state will complete successfully; if more than
one Reader want to change to Writer than one of them *has* to drop the
lock completely, presumably leaving some data structure in an
inconsistent state.

Whether or not the Upgrader state is a win I think depends a heck of a
lot on how it is actually *used*. It should not be used if dropping
the lock is OK -- then getting a Reader lock is appropriate -- only if
one would have to otherwise use a Writer lock.

-hpa

-- 
    PGP: 2047/2A960705 BA 03 D3 2C 14 A8 A8 BD  1E DF FE 69 EE 35 BD 74
    See http://www.zytor.com/~hpa/ for web page and full PGP public key
Always looking for a few good BOsFH.  **  Linux - the OS of global cooperation
        I am Baha'i -- ask me about it or see http://www.bahai.org/