This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: why does rwlock prefer readers by default?


On Tue, 2014-05-27 at 21:38 +0200, OndÅej BÃlka wrote:
> On Fri, May 23, 2014 at 04:40:43PM +0200, Torvald Riegel wrote:
> > On Fri, 2014-05-23 at 13:59 +0200, OndÅej BÃlka wrote:
> > > On Mon, May 12, 2014 at 04:20:22PM +0200, Torvald Riegel wrote:
> > > > On Sat, 2014-05-10 at 19:04 +0200, OndÅej BÃlka wrote:
> > > > > On Wed, May 07, 2014 at 12:33:51PM +0200, Torvald Riegel wrote:
> > > > > > POSIX makes it an implementation-defined choice whether readers or
> > > > > > writers are preferred.  Our current implementation's default is that
> > > > > > readers are to be preferred.  I couldn't find the rationale for this;
> > > > > > does anybody know what it was?
> > > > > > 
> > > > > > Otherwise, if this was an arbitrary choice, what do you all think the
> > > > > > default should be?  Can we change it?  Should we change it to preferring
> > > > > > writers?
> > > > > 
> > > > > I realized that for this discussion we should sort issues with assembly
> > > > > rwlock implementations first. If we decide that some behaviour is
> > > > > preffered we should keep it consistent on all architectures or it will
> > > > > remain undefined for crossplatform programs.
> > > > > 
> > > > > It need either maintainers review and modify rwlock code or remove
> > > > > assembly implementation. As I doubt that now assembly helps I would
> > > > > check architectures if that is case before doing change.
> > > > 
> > > > The background for my question is a new rwlock implementation using a
> > > > different algorithm, and having no assembly variants. Thus, this would
> > > > be independent of what you seem to think about.
> > > 
> > > No torvald, algoritm is worthless if its performance regression, you
> > > should be able to show this, including comparison versus existing assembly
> > > variants. Establishing that these variants do not help performance would
> > > simplify these matters.
> > 
> > Well, I wouldn't propose a change to a new algorithm if it wouldn't
> > perform better, would I?  So, if a new algorithm performs better
> > (assembly or generic), this is independent of the question old-generic
> > vs. old-assembly -- which is what I pointed out.
> 
> That does not follow

It does.  I predicated my statement on the condition that the new
algorithm would perform better (than assembly or generic).  Which
includes the concern you voiced below.

> if applications rarely lock for writes and
> read/write collisions are rare then decision if we prefer reader or
> writter will not matter at all but performance would depend mostly on
> microoptimizations. Could you show it is not case?  




Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]