在 2026-6-30 22:41, Jakub Jelinek 写道:
On Tue, Jun 30, 2026 at 10:27:39PM +0800, LIU Hao wrote:Attached are four patches for libgomp.Please don't include 4 different patches in one mail.
OK I will send new messages separately.
From f641adac6d35f241118fc715ffc40b2b82146a60 Mon Sep 17 00:00:00 2001 From: LIU Hao <[email protected]> Date: Tue, 30 Jun 2026 10:17:12 +0800 Subject: [PATCH 9201/9204] libgomp/team: Fix a race condition `gomp_thread_start_data::handle` is set by `pthread_create()`. If the thread starts execution before `pthread_create()` stores the handle, it may be left uninitialized. The fix is to obtain the handle from `pthread_self()`. libgomp/ChangeLog: * team.c (gomp_thread_start): Get reflexive handle with `pthread_self()`. Signed-off-by: LIU Hao <[email protected]>Please make this conditional on the targets which actually need it. E.g. with glibc there is a guarantee that the handle is stored before the thread is spawned and so this patch just slows down performance critical part of code. Given that nobody reported a problem with this on other arches (musl, darwin, ...), perhaps the race condition doesn't exist there either.
This is not needed when using winpthreads on Windows. I observe this potential race in an attempt to make libgomp buildable for the win32 thread model.
As a matter of fact, this is explicitly unguaranteed by POSIX: (https://pubs.opengroup.org/onlinepubs/9799919799/functions/pthread_create.html) APPLICATION USAGE There is no requirement on the implementation that the ID of the created thread be available before the newly created thread starts executing. The calling thread can obtain the ID of the created thread through the thread argument of the pthread_create() function, and the newly created thread can obtain its ID by a call to pthread_self(). -- Best regards, LIU Hao
OpenPGP_signature.asc
Description: OpenPGP digital signature
