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: Tue, 27 May 2014 21:38:11 +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> <1400856043 dot 6984 dot 164 dot camel at triegel dot csb>
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, 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?