[<prev] [next>] [day] [month] [year] [list]
Message-ID: <20140817064913.GA9583@brightrain.aerifal.cx>
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.
