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, 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?  


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