Fix background thread initialization race #1
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The race condition happens when per-cpu arenas and background threads features are enabled:
malloc()first -> startsmalloc_init_hard()malloc_init_hard(), Threads B, C, D also callmalloc()arena_init()->arena_new_create_background_thread()->background_thread_create(arena_ind=12, etc.)background_thread_create(tsd, 0)) yetThe initialization has locks, but arena creation for different arenas can proceed in parallel as soon as
malloc_init_state = initializedandinit_lockis released, and thebackground_thread_create(tsd, 0)call happens late inmalloc_init_hard()(after arenas are already being created by other threads).This bug won't be noticeable for applications that have single-threaded initialization path, but in case of JVM I observed the following threads allocating concurrently at startup:
Reproducer
Can be reproduced with QuestDB's rt binary on Linux and the following script:
When
jemalloc_bg_thd threads: 0gets printed, it means that jemalloc's background threads didn't start due to the race.