[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20190905133414.GE9017@brightrain.aerifal.cx>
Date: Thu, 5 Sep 2019 09:34:14 -0400
From: Rich Felker <dalias@...c.org>
To: "zhaohang (F)" <zhaohang14@...wei.com>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: src/thread/pthread_create: Why prio of child thread is
set by himself
On Thu, Sep 05, 2019 at 02:14:36AM +0000, zhaohang (F) wrote:
> In the function pthread_create, father thread will wait child if
> attr._a_sched is set, after SYS_clone is finished.Child thread will
> set his prio in entry 'start', and then wake father thread to
> continue.
>
> But consider this kind of situation, there are three threads: A with
> prio 51, B with prio 30, and C with prio 20 created by A, and there
> is only simplest sched policy 'FIFO'.
>
> When system starts, A is running because A is higher than B, then A
> uses pthread_create to create C. After C is cloned, A wait for C to
> set prio and wake him up, but after C set his prio to 20, B will be
> sched. And if B won't exit, A and C will never get sched, even if A
> is higher than B. Maybe this is a kind of priority inversion.
>
> So why prio of child is set by himself rather than father? If prio
> of child is set by father, something will go wrong? Or other
> considerations?
I think you're correct in your analysis of this problem; I'm going to
look at it more in a bit to make sure.
Originally, pthread_create (in the caller) was responsible for setting
priority; this changed in b8742f32602add243ee2ce74d804015463726899 and
40bae2d32fd6f3ffea437fa745ad38a1fe77b27e as part of trying to trim
down the pthread structure and get init-time-only junk out of it.
However, 04335d9260c076cf4d9264bd93dd3b06c237a639 largely undid that
already, and moved the extra start args to a struct on the new
thread's stack so that it doesn't contribute to size/clutter in struct
pthread. It should be easy to switch back to having the new thread
just wait for the parent to tell it whether priority setup succeeded.
One related issue this also turned up is that exiting in detached
state is probably a bad idea. Depending on priorities, the thread that
failed to start could linger for a long time after pthread_create
returns, potentially causing spurious transient resource exhaustion
with no way to wait for it to subside. At some point we should
probably switch from forcing detached exit to forcing joinable (or
equivalent; forcing linking of pthread_join code is somewhat
undesirable) exit so that when a failed pthread_create returns it's
not consuming any kernel task resources.
Thanks for the report.
Rich
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.
