[Bug libgcc/71744] Concurrently throwing exceptions is not scalable

["gleb at scylladb dot com" <gcc-bugzilla at gcc dot gnu dot org>]

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.