From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.1 required=5.0 tests=DKIM_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED, RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 304F02C509 for ; Fri, 16 Aug 2024 04:52:26 +0200 (CEST) Received: (qmail 13637 invoked by uid 550); 16 Aug 2024 02:52:20 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 13597 invoked from network); 16 Aug 2024 02:52:20 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1723776733; x=1724381533; darn=lists.openwall.com; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=G90vnACIJdINjL6Wp5nBukKm9Les/RfAQY+AgWmq94I=; b=YZe8RitGX/9ucGeB+Qkw4Mz+GqJivl22vaYHmKMrSD1Md2PCGdbV0bJLInuqRP34hv PB58MrLy7vPP5GdQM6rrgXT+AjOEDcVsh6carchWkQPqtGLVbZgJkdymlffPLmSUooAB DPeNS1NuwESF8UHz5b7s0NFeWVHSajFK8YV41bRYCw18SncmUh2iLwUCDBLFZotMmRcf s4v7miQH2sQPPOxhFU4fFgAF4f4/LsSsPbZHXkEPlW6EZUeJbgQofXRVa7PN4LSH2tsy /GStXTQhsWNsa3LjzNoIWW0AYhAmJmXwuLUHT3rVrRL6U/yR9x5H8Tj2E2JnFvnfuE7Q NlYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1723776733; x=1724381533; h=content-transfer-encoding:to:subject:message-id:date:from :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=G90vnACIJdINjL6Wp5nBukKm9Les/RfAQY+AgWmq94I=; b=Ui6lcGanbX72YYBSwkTKChDLrOwsjKen3a2BzTVQ9u80cVPMSMyE2jUSEyQg63Y3vc s/SL9fSI7T+uklUSt22wxq4hZZMb7YqzbFsbLaKAy8h6AYZzb29NO7l2Cc+ezOhq3bEu aOZLQLXyurlboMtmrSN7arboPvGcjfEC6L2cTTO308EhZWtDiAw4fJUl44PbcACaGjBw OqHBnF7jli6KhY8KiPo82alAG47CgHnYzIOYAYONin8fBvot5x54gdX3baLmDDLpeJ62 1P7zW1DcNvR3Ay2hScDSn4EaXicA5+A2wuu0lEU3MugX59pWhRi7gASol1lcwwY5zdZk CVfA== X-Gm-Message-State: AOJu0YyPYDv89QuwBVLRYaVzl7FxK+ormi4lGHxZvzgObBuIL0gcSRvx CFebQO+v4zOwjySnNaYM6HkHOhV41bo6AZP8xhAJX8w6elNmpOVo4fmgsDOcq8U7kDxTOLsOEQK on+Vo3M86SlT+YXiyW3BHZBCbYrgFZJNQpxY= X-Google-Smtp-Source: AGHT+IF8fj/i4NtaSUPKcouKJ04oxxBYnpa1xmWIrWn6TN4f6v1rlH72JCVYmsoukI4h/tBlrebaIh0BQn/OWGfA7m8= X-Received: by 2002:a05:6512:3046:b0:532:fb9e:a175 with SMTP id 2adb3069b0e04-5331c691504mr1226835e87.6.1723776732226; Thu, 15 Aug 2024 19:52:12 -0700 (PDT) MIME-Version: 1.0 From: Zibin Liu Date: Fri, 16 Aug 2024 10:51:53 +0800 Message-ID: To: musl@lists.openwall.com Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: [musl] ptc in pthread Hi, I=E2=80=99m not sure if this is the appropriate mailing list for my questio= n. If it isn't, I=E2=80=99d appreciate it if someone could direct me to the corre= ct one. I=E2=80=99m currently studying pthreads and related concepts, and I=E2=80= =99ve come across some code in pthread_create.c that I find a bit confusing. In src/thread/pthread_create.c, I noticed the following: int __pthread_create(pthread_t *restrict res, const pthread_attr_t *restrict attrp, void *(*entry)(void *), void *restrict arg) { ...... __acquire_ptc(); ...... __release_ptc(); ...... fail: __release_ptc(); return EAGAIN; } It appears that when pthread_create is called, it acquires a lock (using __acquire_ptc()) and releases it afterward. I=E2=80=99m wondering wh= y this locking mechanism is necessary. Additionally, I observed that a related lock is acquired during dlopen in ldso/dynlink.c: void *dlopen(const char *file, int mode) { ...... __inhibit_ptc(); ...... end: ...... __release_ptc(); ...... return p; } >From this, it seems that when dlopen is called, creating a new pthread is not allowed during the process. Does this mean that it=E2=80=99s entirel= y prohibited to create any threads (even if one were to use a custom thread library specifically within dlopen) during the execution of dlopen? I also traced the commit logs and found that the 'ptc' mechanism was introduced in commit dcd6037, with the following message: > I've re-appropriated the lock that was previously used for __synccall > (synchronizing set*id() syscalls between threads) as a general > pthread_create lock. it's a "backwards" rwlock where the "read" > operation is safe atomic modification of the live thread count, which > multiple threads can perform at the same time, and the "write" > operation is making sure the count does not increase during an > operation that depends on it remaining bounded (__synccall or dlopen). > in static-linked programs that don't use __synccall, this lock is a > no-op and has no cost. Despite this, I=E2=80=99m still unclear on why dlopen needs to ensure that = the thread count does not increase. Could someone provide more details on this?