From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/14610 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: src/thread/pthread_create: Why prio of child thread is set by himself Date: Thu, 5 Sep 2019 09:34:14 -0400 Message-ID: <20190905133414.GE9017@brightrain.aerifal.cx> References: <59FB1E003EF3A943BD6BAD197ABD4D6A2A9CC4@dggemi524-mbx.china.huawei.com> Reply-To: musl@lists.openwall.com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="235559"; mail-complaints-to="usenet@blaine.gmane.org" User-Agent: Mutt/1.5.21 (2010-09-15) Cc: "musl@lists.openwall.com" To: "zhaohang (F)" Original-X-From: musl-return-14626-gllmg-musl=m.gmane.org@lists.openwall.com Thu Sep 05 15:36:51 2019 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by blaine.gmane.org with smtp (Exim 4.89) (envelope-from ) id 1i5rwP-000z5U-Gc for gllmg-musl@m.gmane.org; Thu, 05 Sep 2019 15:36:49 +0200 Original-Received: (qmail 9757 invoked by uid 550); 5 Sep 2019 13:36:45 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 9737 invoked from network); 5 Sep 2019 13:36:45 -0000 Content-Disposition: inline In-Reply-To: <59FB1E003EF3A943BD6BAD197ABD4D6A2A9CC4@dggemi524-mbx.china.huawei.com> Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:14610 Archived-At: 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