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.