From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/5870 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Roadmap, progress on thread stuff Date: Sun, 17 Aug 2014 02:49:13 -0400 Message-ID: <20140817064913.GA9583@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1408258173 20491 80.91.229.3 (17 Aug 2014 06:49:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 17 Aug 2014 06:49:33 +0000 (UTC) To: musl@lists.openwall.com Original-X-From: musl-return-5876-gllmg-musl=m.gmane.org@lists.openwall.com Sun Aug 17 08:49:27 2014 Return-path: Envelope-to: gllmg-musl@plane.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1XIuHO-0000XQ-Ja for gllmg-musl@plane.gmane.org; Sun, 17 Aug 2014 08:49:26 +0200 Original-Received: (qmail 28525 invoked by uid 550); 17 Aug 2014 06:49:25 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 28517 invoked from network); 17 Aug 2014 06:49:25 -0000 Content-Disposition: inline User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:5870 Archived-At: Hi all, I've recently rearranged the roadmap on the wiki to account for the current momentum for thread/synchronization related improvements and Jens' work on C11 threads. My aim is now to focus on these topics while they're fresh in my mind for the current release cycle, and resume other planned work (iconv, IDN, locale stuff, etc.) for the following release. Recent commits have addressed several longstanding bugs related to mutexes, some of which were known open issues for a long time and others of which I found while fixing known issues or testing changes: - False ownership of mutexes due to TID reuse. An identical bug exists for stdio FILE locks too, since they are specified to behave as recursive mutexes. Rather than embedding a pthread_mutex_t in the FILE struct so it can be a member in the robust list, I'm thinking of just having flockfile/funlockfile keep a count of the number of FILEs locked by the thread, and walking the whole open-file-list at thread exit to perma-lock them all if the count is nonzero. - Race where unrecoverable robust mutexes falsely show as busy/locked rather than unrecoverable when multiple threads attempt to lock them at the same time. This condition should not be too difficult to produce, so maybe we can get a regression test to demonstrate the bug and that it's been fixed. - Lack of compiler barriers in robust-list manipulation. I don't think this is testable since aliasing considerations would make it almost impossible for the compiler to reorder these operations. - Possible failure-to-wake deadlock with process-shared robust mutexes, due to missing waiter flag on the lock value. This should be testable without any race conditions, so I'd like to get a test case for it added. The big issue which remains open right now is Jens' condition variable issue. As described in another email, I have a solution (with two variants) so it's just a matter of implementing it. This is my next major agenda item. I'd also like to review self-synchronized destruction issues for all synchronization primitives and for stdio FILEs and fix any that remain. This might require some additional synchronization in the destroy functions. There's also the issue Jens raised of sending spurious futex wakes on already-freed addresses. I don't believe this is critical (it does not affect any musl-internal use of futexes, only potentially third-party use of futex) but I do want to test solutions with FUTEX_WAKE_OP and consider adopting them if they improve (or at least don't harm) performance. Rich