[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABKykw=G8=DwnS1sXw0pzB-TT49Z_v9LqVACGoFFh8VZveMkew@mail.gmail.com>
Date: Fri, 16 Aug 2024 10:51:53 +0800
From: Zibin Liu <ghostfly23333@...il.com>
To: musl@...ts.openwall.com
Subject: ptc in pthread
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?
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.
