[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <aLnMjjE5T0800mZr@voyager>
Date: Thu, 4 Sep 2025 19:29:50 +0200
From: Markus Wichmann <nullplan@....net>
To: musl@...ts.openwall.com
Subject: Re: MUSL - malloc - Multithread Suggestion
Am Thu, Sep 04, 2025 at 07:33:10AM -0400 schrieb Greg McPherran:
> Hi, perhaps a thread_local (e.g. C23) memory pool would separate
> malloc cleanly for each thread, with no performance issue, e.g. mutex
> etc?
The idea is well-known, and a library that implements can be found under
the name tcmalloc.
The thread_local keyword, however, cannot be used for a few reasons. One
is general: You must keep a thread-local arena alive for as long as it
has active allocations, since in C, one thread can allocate an object
and give it to another thread. So automatic deallocation when the thread
ends is out of the question.
The other is technical: The keyword is basically implemented on Linux
the same as the __thread extension keyword, which in the end uses ELF
TLS. But musl cannot at the moment use ELF TLS for itself in dynamic
linking mode because the dynamic loader is not set up for that. Fixing
that would require making the stage 2 relocation of the linker skip TLS
relocations as well, and also not using any code that uses TLS until the
stage 3 relocation has happened. Putting it in the allocator is
therefore not an option at all, since we need an allocator to get to the
stage 3 relocation.
I also must correct one thing: Due to the allocations being able to be
shared, even with thread-local arenas the implementation needs locking,
since other threads might be concurrently freeing an object in the same
arena. But there should be less contention, yes.
Ciao,
Markus
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
