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: [PATCH v4] Make bindresvport() function to multithread-safe


On Thu, Oct 25, 2012 at 11:46:34AM -0400, Carlos O'Donell wrote:
> > (2) The runtime cost of this function is bounded by syscalls, so
> > optimizing userspace code for performance is mostly useless. (Not
> > entirely since the locking cost could invalidate cache in other
> > threads, but I still suspect this will be very rare.)
> 
> Now this is a *great* counter-argument to using __thread variables.
> 
> However, I still don't buy that this is the right way forward for
> the long-term.

I'm not convinced as to which approach is better either. I just think
the topic merits discussion rather than making arbitrary decisions
based on premature optimization.

> > Of course for this one function, the cost (a few bytes of TLS) does
> > not matter. I'm more thinking from a general policy perspective;
> > adding TLS all over the place will eventually add up. It would be even
> > worse if this were initialized TLS, since that adds runtime cost too.
> 
> I agree that adding TLS all over the place will eventually add up,
> *but* the number of cores on devices is going up and quickly.
> If we keep adding locks we're bound to get hosed for performance
> since locks require complex coherency protocols between the cores.
> If we could elide the locks and simply use local data it's a huge
> concurrency win.

The bind() in kernelspace is already going to involve host-global
locks, so concurrency is not possible.

> I can't condone the use of a lock when a small amount of TLS solves
> the problem, even if the TLS is repeated for every process in the
> system. Even then we could switch to some lazy TLS allocation
> (which we have) for more kinds of TLS variables and it's a win-win.

Lazy TLS allocation means an otherwise-correct program could
unexpectedly crash on the first usage if memory has been exhausted. I
consider this an unacceptably bad quality-of-implementation issue.
It's certainly unacceptable for applications with robust/realtime
requirements.

In reality, it seems like glibc's libc.so requires TLS from the moment
it starts, so success/failure will be resolved at startup, at least
for the main thread. It's unclear to me however whether new threads
have TLS reserved for libc.so as soon as they start, or whether it's
allocated on the first usage (which will probably be almost
immediately since errno seems to be using TLS rather than a member of
the pthread structure these days -- am I right?).

I know this is rather tangential to the topic at hand, but I think
it's an important policy discussion to have since the current
direction seems to be leading towards making glibc unusable for
applications with robustness requirements.

> I'm open to more conversation on this topic since it's a policy
> issue that will continue to be relevant in the years to come.

Indeed.

Rich


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