This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] New condvar implementation that provides stronger ordering guarantees.
- 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>, Marcus Shawcroft <marcus dot shawcroft at gmail dot com>, "Joseph S. Myers" <joseph at codesourcery dot com>, Richard Henderson <rth at redhat dot com>, "Carlos O'Donell" <codonell at redhat dot com>, Mike Frysinger <vapier at gentoo dot org>, Chung-Lin Tang <chunglin_tang at mentor dot com>, Andreas Krebbel <krebbel at linux dot ibm dot com>, Chris Metcalf <cmetcalf at tilera dot com>, David Miller <davem at davemloft dot net>, Darren Hart <dvhart at infradead dot org>
- Date: Mon, 13 Jul 2015 20:57:27 +0200
- Subject: Re: [PATCH] New condvar implementation that provides stronger ordering guarantees.
- Authentication-results: sourceware.org; auth=none
- References: <1424456307 dot 20941 dot 122 dot camel at triegel dot csb> <1431713889 dot 25070 dot 17 dot camel at triegel dot csb> <20150701221513 dot GA29236 at domone> <1435843502 dot 10077 dot 12 dot camel at localhost dot localdomain> <20150702214838 dot GA10291 at domone> <1435914205 dot 10077 dot 45 dot camel at localhost dot localdomain> <20150703112848 dot GA4360 at domone> <1435932055 dot 10077 dot 49 dot camel at localhost dot localdomain> <20150711133536 dot GA7711 at domone>
On Sat, 2015-07-11 at 15:35 +0200, OndÅej BÃlka wrote:
> On Fri, Jul 03, 2015 at 04:00:55PM +0200, Torvald Riegel wrote:
> > On Fri, 2015-07-03 at 13:28 +0200, OndÅej BÃlka wrote:
> > > On Fri, Jul 03, 2015 at 11:03:25AM +0200, Torvald Riegel wrote:
> > > > On Thu, 2015-07-02 at 23:48 +0200, OndÅej BÃlka wrote:
> > > > Yes, we may not just be dealing with short critical sections. However,
> > > > if we have long critical sections on the waiter side, and broadcast or
> > > > many signals wake many waiters, then some potential slowdown due to
> > > > contention is less important because the program isn't scalable in the
> > > > first place (ie, has many long critical sections that need to be
> > > > serialized). Specifically, one of the long critical sections will get
> > > > the lock; while it has it, the others will sort things out, in parallel
> > > > with the critical section that is running. That means we may do some
> > > > extra work, but it won't slow down the critical section that has the
> > > > lock.
> > > >
> > > My argument was that a other method is from different thread but waiters
> > > could be fast. So it could be hard to distinguish between these.
> > >
> > > A extra work matters if program used multiple threads effectively and
> > > could run computation instead of rescheduling threads that will only
> > > find lock locked.
> >
> > If a program relies on threads waiting to acquire a lock to give up the
> > compute resource so that it can run other stuff instead, the program
> > isn't using threads efficiently. It's oversubscribing the machine, and
> > the context switches will matter more than a bit of contention.
> >
> Thats false as it doesn't have to be one program at all, it could affect
> different process on machine.
Same thing, it's inefficient in this case too. Granted, many programs
just assume that they have the machine completely for themselves, and
that's often the case -- but that doesn't mean that this is optimal
behavior in general. Providing abstractions to make this easier to be
handled correctly is future work.