lkml.org 
[lkml]   [2013]   [Nov]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
SubjectRe: [PATCH v6 3/5] qrwlock: Enable fair queue read/write lock
From
On Tue, Nov 12, 2013 at 6:48 AM, Waiman Long <Waiman.Long@hp.com> wrote:
> By default, queue rwlock is fair among writers and gives preference
> to readers allowing them to steal lock even if a writer is
> waiting. However, there is a desire to have a fair variant of
> rwlock that is more deterministic. To enable this [..]

Is there really any point in having the option for unfair at all?

From your timings, it looks like the unfair locks are more expensive
for the writer side, but since pretty much the whole point of rwlocks
is when readers are the common case, I don't think we care.

And I'm not at all convinced we want the complexity of two different
kinds of rwlocks with different semantics and extra code for said
semantics..

Your *original* fair rwlocks were unusable, since they didn't allow
for the irq semantics that most users need, but afaik your current
version always makes an irq/bh-context reader work even when the lock
is otherwise trying to be fair, so this whole dual behavior seems to
be largely pointless.

No?

Linus


\
 
 \ /
  Last update: 2013-11-18 19:41    [W:0.576 / U:0.808 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site