The difference is that any number of readers may hold the lock at the
same time. An update lock does not conflict with a read lock.
It's the difference between an update lock and a read lock that is
more subtle. Only one update lock may exist at a time, and has
the ability to be upgraded to a write lock without dropping the lock.
From: hpa@transmeta.com (H. Peter Anvin)
Date: 21 Sep 1997 07:20:47 GMT
The way I read it, the "update lock" operation supports
transitioning from a read lock to a write lock guaranteeing that no
other writers can come in between, as you could if you just
released the read lock and grabbed a write one.
I sometimes can't see the forest from the trees because I think
everyone has seen how all of these smp locking primitives are
implemented "traditionally".
Almost all of the sleeping rwlock implementations I've ever seen allow
any reader to make upgrade attempts to become a writer, and also
conversely they allow any writer to downgrade into a reader.
Code sequences using these look perhaps something like:
sleep_read_lock(&list->rwlock);
obj = futz_around(list);
if(obj == it) {
sleep_upgrade_lock(&list->rwlock);
remove(list, obj);
sleep_write_unlock(&list->rwlock);
return obj;
}
sleep_read_unlock(&list->rwlock);
return NULL;
or whatever... So the claims of the upgrade facility are:
1) An upgrader does not conflict with readers.
: In my example approach the same is true since readers
: cannot conflict with themselves ;-)
2) An upgrader can upgrade to a writer without dropping the rwlock
for a single moment. (this is essentially what HPA points out)
: Same is true for the scheme I suggested.
3) Upgrader facility allows you to verify prerequisites for an op,
then upgrade to write and do the operation.
: Again, same is true in my scheme.
4) An upgrader conflicts with writers and other upgraders, but not
with read locks.
: This is insanity. You are adding complexity where there is none,
: this statement is what is convincing me that an explicit upgrader
: facility is utter nonsense.
: This is not to say that the effect isn't necessary, but it need
: not be asked for!
: When a reader expresses desire for an upgrade, disallow any
: new readers to enter, so that existing readers can pile out
: and let the upgrader in. This is sort of the heuristic used
: when a writer walks in, hold out new readers.
: The relative prioritization between upgraders and "pure-writers"
: is another issue, but I think Schimmel's book makes some
: constructive commentary about this very thing.
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.
This is my take on sleeping read/write lock implementations.
Another issue, if a lock is mostly used for "find and remove", "find
and update that" type activities (and this is what upgrading can be
used for, however implemented), then you might just want a sleeping
spinlock in there anyways. It's cheaper and much easier to verify.
However for lookup entensive objects (buffer cache, page cache,
dcache, etc.) rwlocks are definately what you want, because these are
the cases where you want all the parallelism. (Just from casual scans
of header files of various commercial unixes, and TPC benchmark
results, I will tell you that it seems that an invariant
characteristic of those whole perform incredibly on SMP TPC runs use a
seperate rwlock for every hash chain in their buffer cache....)
Maybe we'll call our sleeping spinlocks "ziplocks". 8-)
Later,
David "Sparc" Miller
davem@caip.rutgers.edu