This is the mail archive of the
mailing list for the glibc project.
Re: why does rwlock prefer readers by default?
- From: Torvald Riegel <triegel at redhat dot com>
- To: OndÅej BÃlka <neleai at seznam dot cz>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Fri, 23 May 2014 16:40:43 +0200
- Subject: Re: why does rwlock prefer readers by default?
- Authentication-results: sourceware.org; auth=none
- References: <1399458831 dot 32485 dot 12625 dot camel at triegel dot csb> <20140510170443 dot GC11500 at domone> <1399904422 dot 32485 dot 20021 dot camel at triegel dot csb> <20140523115939 dot GC15258 at domone dot podge>
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.