On Thu, 2013-05-30 at 11:28 +0200, Jakub Jelinek wrote: > On Thu, May 30, 2013 at 11:21:08AM +0200, Torvald Riegel wrote: > > On Tue, 2013-05-28 at 20:30 +0200, Florian Weimer wrote: > > > On 05/28/2013 08:09 PM, Václav Zeman wrote: > > > > > > > If the bottleneck is really in glibc, then you should probably ask them > > > > to fix it. Could the mutex be changed rwlock instead? > > > > > > rwlocks don't eliminate hardware contention, so I doubt they'd be a win > > > here. > > > > Indeed. Reader-writer locks guarantee the critical section, even the > > readers, that they run mutually exclusive with writers. So whatever you > > do while holding the lock, the protected data won't change. That > > restricts what we can do, because we need to actively prevent writers > > from doing things, which means making your read operation visible to > > others (unless you can stop the writers in some other funny ways). > > > > However, we only seem to need an atomic snapshot here AFAIU, in which > > case we can do stuff like reading the data optimistically, verifying > > that we read consistent data, and retrying if we didn't. > > Please look at the mail I've posted in this threads, there are lots of ABI > complexities involved and for many solutions it would require to change both > glibc and gcc (the latter conditionally on glibc), which makes it a long > term process.
I did read those emails (but didn't actually look at the dynamic loader code). What I was commenting on is that there are other ways to synchronize in case we need an atomic snapshot (if it's such a case), which are probably more efficient than a lock. I wasn't at all commenting on whether it would be simple to make such a change, or even worth doing it for the potential performance gain.
