[musl] A question about the implementation of pthread_create and start

[musl] A question about the implementation of pthread_create and start

[IMMING]

[-- Attachment #1: Type: text/plain, Size: 2369 bytes --]

Hi, I would like to ask a question about the implementation of pthread_create and start （musl v1.2.5）

My question is as follows, here is the code:
-----------------
int __pthread_create(pthread_t *restrict res, const pthread_attr_t *restrict attrp, void *(*entry)(void *), void *restrict arg)

...
	if&nbsp;(ret&nbsp;<&nbsp;0)&nbsp;{ 
		ret&nbsp;=&nbsp;-EAGAIN; 
	}&nbsp;else&nbsp;if&nbsp;(attr._a_sched)&nbsp;{ 
		ret&nbsp;=&nbsp;__syscall(SYS_sched_setscheduler, 
			new-&gt;tid,&nbsp;attr._a_policy,&nbsp;&amp;attr._a_prio); 
		if&nbsp;(a_swap(&amp;args-&gt;control,&nbsp;ret&nbsp;?&nbsp;3&nbsp;:&nbsp;0)&nbsp;==&nbsp;2)  <- line 1 
			__wake(&amp;args-&gt;control,&nbsp;1,&nbsp;1);                    <- line 2 
		if&nbsp;(ret) 
			__wait(&amp;args-&gt;control,&nbsp;0,&nbsp;3,&nbsp;0);                <- line 3
 
	}
...
-----------------
static&nbsp;int&nbsp;start(void&nbsp;*p) 
 ...
	struct&nbsp;start_args&nbsp;*args&nbsp;=&nbsp;p; 
	int&nbsp;state&nbsp;=&nbsp;args-&gt;control; 
	if&nbsp;(state)&nbsp;{ 
		if&nbsp;(a_cas(&amp;args-&gt;control,&nbsp;1,&nbsp;2)&nbsp;==&nbsp;1)           <- line 4 
			__wait(&amp;args-&gt;control,&nbsp;0,&nbsp;2,&nbsp;1);              <- line 5 
		if&nbsp;(args-&gt;control)&nbsp;{ 
			__syscall(SYS_set_tid_address,&nbsp;&amp;args-&gt;control); <- line 6 
			for&nbsp;(;;)&nbsp;__syscall(SYS_exit,&nbsp;0);              <- line 7 
		} 
	} 
	__syscall(SYS_rt_sigprocmask,&nbsp;SIG_SETMASK,&nbsp;&amp;args-&gt;sig_mask,&nbsp;0,&nbsp;_NSIG/8); 
...
-----------------

I think the calling route should be like this：


1.line 4(child thread)
2.line 5(child thread wait)
3.line 1(parent thread&nbsp;if SYS_sched_setscheduler false)
4.line 2(parent thread wake child thread)
5.line 3(parent&nbsp;thread wait if SYS_sched_setscheduler false) <- Problem point
6.line 6(child thread)

7.line 6(child thread exit)



My question is, if SYS_sched_setscheduler returns an error (a non-zero value), the parent thread will remain in a wait state and I have not found a way to wake it, 
which will cause the parent thread to remain stuck in the pthread_create function and unable to return

1.Is my analysis process correct?
2.Is the situation where the parent thread gets stuck in the waite as expected？

[-- Attachment #2: Type: text/html, Size: 35978 bytes --]

Re: [musl] A question about the implementation of pthread_create and start

[Markus Wichmann]

Am Mon, May 27, 2024 at 08:22:42PM +0800 schrieb IMMING:
> Hi, I would like to ask a question about the implementation of pthread_create and start （musl v1.2.5）
>

Bloody hell, please fix your mail client settings to stop emitting these
HTML entities in the plain text! Our MUAs are grown up, they can handle
non-ASCII if it's properly declared.

> My question is, if SYS_sched_setscheduler returns an error (a non-zero
> value), the parent thread will remain in a wait state and I have not
> found a way to wake it, which will cause the parent thread to remain
> stuck in the pthread_create function and unable to return
>
> 1.Is my analysis process correct?

No. The call to SYS_set_tid_address sets the child's TID address to
&a->control, and the CLONE_CHILD_CLEARTID flag. This means that as soon
as the child exits, the kernel will set that address to 0 and perform a
futex wake on it. This is the same mechanism normally used for the
thread list on exit.

This means that the parent thread will be woken up as soon as the child
thread exits. Reason is that this way, the parent thread gets to clean
up the child memory by unmapping it. The only other way to achieve the
same thing would be to detach the child thread and let it clean up
itself. But this has the problem that we would need to publish the child
thread in the list, and it would be visible to the other threads, even
though it is at that point doomed to exit.

So it is just cleaner for the parent to clean up, since the parent needs
the cleanup code anyway in case the __clone() fails.

> 2.Is the situation where the parent thread gets stuck in the waite as
> expected？

It is not expected that the parent gets stuck indefinitely. Once the
failure of sched_setscheduler has been communicated, it is expected that
the child should exit quickly, and that's when the parent is woken up.
Or have you identified a case where the parent does get stuck forever?
Ciao,
Markus