Date: Sun, 17 Aug 2014 02:49:13 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com Subject: Roadmap, progress on thread stuff 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
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.