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: Wed, 28 May 2014 11:16: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> <20140523115939 dot GC15258 at domone dot podge> <1400856043 dot 6984 dot 164 dot camel at triegel dot csb> <20140527193811 dot GA21316 at domone dot podge>
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?