mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: musl@lists.openwall.com
Subject: Re: Draft outline of thread-list design
Date: Tue, 12 Feb 2019 15:23:55 -0500	[thread overview]
Message-ID: <20190212202355.GP23599@brightrain.aerifal.cx> (raw)
In-Reply-To: <20190212182625.GA24199@brightrain.aerifal.cx>

On Tue, Feb 12, 2019 at 01:26:25PM -0500, Rich Felker wrote:
> Here's a draft of the thread-list design, proposed previously as a
> better way to do dynamic TLS installation, and now as a solution to
> the problem of __synccall's use of /proc/self/task being (apparently
> hopelessly) broken:
> 
> 
> 
> Goal of simplicity and correctness, not micro-optimizing.
> 
> List lock is fully AS-safe. Taking lock requires signals be blocked.
> Could be an rwlock, where only thread creation and exit require the
> write lock, but this is not necessary for correctness, only as a
> possible optimization if other operations with high concurrency
> needing access would benefit.
> 
> 
> pthread_create:
> 
> Take lock, create new thread, on success add to list, unlock. New
> thread has new responsibility of unblocking signals, since it inherits
> a fully-blocked signal mask from the parent holding the lock. New
> thread should be created with its tid address equal to the thread list
> lock's address, so that set_tid_address never needs to be called
> later. This simplifies logic that previously had to be aware of detach
> state and adjust the exit futex address accordingly to be safe against
> clobbering freed memory.
> 
> pthread_exit:
> 
> Take lock. If this is the last thread, unlock and call exit(0).
> Otherwise, do cleanup work, set state to exiting, remove self from
> list. List will be unlocked when the kernel task exits. Unfortunately
> there can be a nontrivial (non-constant) amount of cleanup work to do
> if the thread left locks held, but since this should not happen in
> correct code, it probably doesn't matter.

It should be possible to eliminate the unbounded time the lock is held
and a lot of the serializing effects (but not all) by switching to
having two lists each with their own lock: live threads and exiting
threads. pthread_exit would start by moving the caller from the live
list to the exiting list, holding both locks. After that, the rest of
the function could run without any lock held until just before exit,
when the exiting thread list lock would need to be taken for the
thread to change its state to exited and remove itself from the list.

With this change, pthread_create and dlopen would only need to
synchronize against the live threads list, and pthread_join would only
need to synchronize against the exiting threads list. Only
pthread_exit and __synccall would need to synchronize with both.

I doubt this change makes sense though, at least not actually moving
the exiting thread to a new list. The expected amount of work between
the unlock and re-lock is much less than the cost of a lock cycle. We
could still use a separate exit lock to reduce the window during which
the live thread list lock has to be held, lowering the serializing
pressure on pthread_create, but I don't think there's actually any
advantage to having lower serialization pressure on create than on
exit, since they come in pairs.

Rich


  reply	other threads:[~2019-02-12 20:23 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-02-12 18:26 Rich Felker
2019-02-12 20:23 ` Rich Felker [this message]
2019-02-14 21:16 ` Alexey Izbyshev
2019-02-14 22:32   ` Rich Felker
2019-02-14 22:54     ` Alexey Izbyshev
2019-02-14 23:19     ` Rich Felker
2019-02-15  0:20 ` Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190212202355.GP23599@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).