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 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.



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