https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71744
--- Comment #15 from torvald at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #14) > Looking at that patchset, I just want to say that the use of TLS in libgcc > is very much undesirable, it affects every program even when not using > exceptions (significant portion of them), especially when it uses that much > (6 * sizeof(void *) * 8 + sizeof(void *) + 2 * 8 = 408 bytes per thread is > significant, plus it uses the slow local dynamic TLS model. I agree. > Similarly, the 64 recursive locks in libc, again, significant amount of > memory > per process that doesn't care about exceptions, That might be reducable if we build custom locks and don't use pthread ones, but we'll at least have 64b per lock. > and especially signficiant > slowdown on dlopen/dlclose. While some programs abuse exceptions for normal > control flow, others abuse dlopen/dlclose. > > A rwlock ought to be better, but I don't think we have recursive rwlock in > libc rdlock can be recursive, rwlock cannot. It is something we could add with not much effort in a custom rwlock, I think. > yet (all we need is being able to recursively lock it for writing, for > reading > we might not need to allow recursion in this case). Not having to deal with recursive rdlock can make things easier for the rwlock implementation. > Plus the current rwlock > implementation still takes uses a per-process lock to guard the inner > operations > on the rwlock, so while rwlock helps with longer critical sections, for very > short ones it likely doesn't scale all that well. This will change as soon as my new rwlock is upstream. Especially short rdlock sections will be much faster.
