lkml.org 
[lkml]   [2008]   [Aug]   [21]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [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


\
 
 \ /
  Last update: 2008-08-21 23:35    [from the cache]
©2003-2011 Jasper Spaans