Messages in this thread | | | Date | Thu, 21 Aug 2008 14:26:05 -0700 | From | "H. Peter Anvin" <> | Subject | Re: [RFC PATCH] Writer-biased low-latency rwlock v8 |
| |
Linus Torvalds wrote: > > Because that is already crap. > > Go look at my code once more. Go look at how it has 128 bits of data, > exactly so that it DOES NOT HAVE TO LIMIT THE NUMBER OF READERS. > > And then go look at it again. > > Look at it five times, and until you can understand that it still uses > just a 32-bit word for the fast-path and no unnecessarily crap in it, but > it actually has 128 bits of data for all the slow paths, don't bother > emailing me any new versions. > > Please. You -still- apparently haven't looked at it, at least not enough > to understand the _point_ of it. You still go on about trying to fit in > three or four different numbers in that one word. Even though the whole > point of my rwlock is that you need exactly _one_ count (active writers), > and _one_ bit (active reader) and _one_ extra bit ("contention, go to slow > path, look at the other bits ONLY IN THE SLOW PATH!") > > That leaves 30 bits for readers. If you still think you need to "limit the > number of readers", then you aren't getting it. >
First of all, let me say I don't pretend to understand formally how you deal with overflow-after-the-fact, as unlikely as it is.
However, it seems to me to be an easy way to avoid it. Simply by changing the read-test mask to $0x80000003, you will kick the code down the slow path once the read counter reaches $0x80000004 (2^29+1 readers), where you can do any necessary fixup -- or BUG() -- at leisure.
This fastpath ends up being identical in size and performance to the one you posted, although yours could be reduced by changing the test to a testb instruction -- at the almost certainly unacceptable expense of taking a partial-register stall on the CPUs that have those.
-hpa
| |