This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: why does rwlock prefer readers by default?
- From: OndÅej BÃlka <neleai at seznam dot cz>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Fri, 23 May 2014 13:59:39 +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>
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.