Roadmap, progress on thread stuff

Roadmap, progress on thread stuff

[Rich Felker]

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