https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #19 from Gleb Natapov <gleb at scylladb dot com> --- (In reply to Jakub Jelinek from comment #18) > (In reply to Gleb Natapov from comment #16) > > Can you suggest an alternative to libgcc patch? Use other TLS model? > > Allocate per thread storage dynamically somehow? > > If we want to use TLS (which I hope we don't), then e.g. a single __thread > pointer with some registered destructor that would free it on process exit > could do the job, and on the first exception it would try to allocate memory > for the cache and other stuff and use that (otherwise, if memory allocation > fails, just take a lock and be non-scalable). > I see that sjlj uses __gthread_setspecific/__gthread_getspecific. Can we do the same here? > > Another alternative, perhaps much better, if Torvald is going to improve > rwlocks sufficiently, would be to use rwlock to guard writes to the cache > etc. too, and perhaps somewhat enlarge the cache (either statically, or > allow extending it through allocation). > I'd expect that usually these apps that use exceptions too much only care > about a couple of shared libraries, so writes to the cache ought to be rare. > As I said in my previous reply, I tested the new rwlock and in congested case it still slows does the system significantly, not the implementation fault, cpu just does not like locked instruction much. Not having a lock will be significantly better.