mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Zibin Liu <ghostfly23333@gmail.com>
To: musl@lists.openwall.com
Subject: [musl] ptc in pthread
Date: Fri, 16 Aug 2024 10:51:53 +0800	[thread overview]
Message-ID: <CABKykw=G8=DwnS1sXw0pzB-TT49Z_v9LqVACGoFFh8VZveMkew@mail.gmail.com> (raw)

Hi,

I’m not sure if this is the appropriate mailing list for my question. If
it isn't, I’d appreciate it if someone could direct me to the correct
one.

I’m currently studying pthreads and related concepts, and I’ve 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’m wondering why
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’s entirely
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’m still unclear on why dlopen needs to ensure that the
thread count does not increase. Could someone provide more details on
this?

             reply	other threads:[~2024-08-16  2:52 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-08-16  2:51 Zibin Liu [this message]
2024-08-16 14:38 ` Markus Wichmann
2024-08-16 15:51   ` Rich Felker
2024-08-16 15:40 ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CABKykw=G8=DwnS1sXw0pzB-TT49Z_v9LqVACGoFFh8VZveMkew@mail.gmail.com' \
    --to=ghostfly23333@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).