Fix libthr initialization from constructors

[kib]

Summary

libthr: switch thread and sleepq memory allocator to crt from libc malloc

There are more complex interactions between malloc and libthr
initialization that can happen if libthr functions are called from ELF
object' constructors, before libthr is initialized.  Break the
dependencies loop by using the private allocator with controlled init.

Reported by:    yuri

pthread_mutex_trylock(): init libthr if needed

Reported by:    yuri


libthr: use atomic_add_int() instead of atomic_fetchadd_int()

the return value is ignored.

[olce]

Switching to __thr_calloc() in _thr_alloc() basically means that the rtld allocator will always be used to allocate thread structures. Could that become a problem (perf, memory fragmentation, etc.)?

[kib]

In D48454#1105479, @olce wrote:

Switching to __thr_calloc() in _thr_alloc() basically means that the rtld allocator will always be used to allocate thread structures. Could that become a problem (perf, memory fragmentation, etc.)?

So far it was not a problem for mutexes. I am not even sure how to measure what you are asking, because threads are cached.

Having fast but mal-functional allocator is not a good deal IMO.

[olce]

In D48454#1105553, @kib wrote:

Having fast but mal-functional allocator is not a good deal IMO.

Well, it's more of a bootstrapping problem than "malfunction", else I agree with you. I'm asking in case that would trigger the need for more work in that area, but given your answer that seems unlikely.