Date: Wed, 04 May 2016 16:56:31 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-threads@FreeBSD.org Subject: [Bug 209233] [patch] pthread_suspend_all_np races with check_suspend Message-ID: <bug-209233-16-GptCO2YCuM@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-209233-16@https.bugs.freebsd.org/bugzilla/> References: <bug-209233-16@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D209233 --- Comment #5 from Lawrence Esswood <le277@cam.ac.uk> --- (In reply to Konstantin Belousov from comment #3) I had a very wonky test that very unreliably failed, now I know why it happ= ens I can probably create a much better one to attach. Your suggestion I think would work. You would also have to change the break condition on the check_suspend loop otherwise if the thread is woken for any reason it will break too early. One question however, what happens if the thread in check_suspend has its NEED_SUSPEND flag set and is signalled somewhere between the loop exit and = the _thr_signal_unblock? I think it won't do another check_suspend / check_defe= rred until it next hits a _thr_ast which might be never. We could maybe extend t= he thread lock to include the _thr_signal_unblock, or have the end of check_suspend make a recursive call. I will try knock up a test case. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-209233-16-GptCO2YCuM>