From: Rich Felker <dalias@libc.org>
To: Florian Weimer <fweimer@redhat.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [PATCH 2/2] manual: Document __libc_single_threaded
Date: Fri, 22 May 2020 13:49:32 -0400 [thread overview]
Message-ID: <20200522174932.GY1079@brightrain.aerifal.cx> (raw)
In-Reply-To: <87h7w727i4.fsf@oldenburg2.str.redhat.com>
On Fri, May 22, 2020 at 07:40:19PM +0200, Florian Weimer via Libc-alpha wrote:
> * Rich Felker:
>
> >> Our discussion focused on the problem that observing a thread count of 1
> >> in pthread_join does not necessarily mean that it is safe to assume at
> >> this point that the process is single-threaded, in glibc's
> >> implementation that uses a simple __nptl_nthreads counter decremented on
> >> the thread itself. This does not cause a low-level data race directly,
> >> but is potentially still incorrect (I'm not quite sure yet).
> >
> > pthread_join necessarily has an acquire barrier (this is a fundamental
> > requirement of the interface contract; join is acquiring the results
> > of the thread) so under some weak assumptions on unsynchronized memory
> > access (e.g. non-tearing, not seeing a value that wasn't stored
> > sometime between the last and next acquire barriers on the observer's
> > side) I think observing it from pthread_join is safe.
>
> Because of the meaning of the variable, it is *completely* safe if there
> are no detached threads, without any further assumptions.
>
> With detached threads an pthread_join observing a thread count of 1 (as
> decreased during thread exit), the validity of setting
> __libc_single_threaded depends on whether the kernel offers something
> that causes a memory write on thread exit. I know of at least two such
I don't follow. Why do you care about the kernel entity exiting here?
You should only care about having a release barrier before the update
to the count, so that seeing the updated count guarantees seeing any
changes to memory made by the exiting detached thread.
Rich
next prev parent reply other threads:[~2020-05-22 17:49 UTC|newest]
Thread overview: 45+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-05-20 18:12 [PATCH 0/2] Add __libc_single_threaded Florian Weimer via Libc-alpha
2020-05-20 18:12 ` [PATCH 1/2] Add the __libc_single_threaded variable Florian Weimer via Libc-alpha
2020-05-21 13:07 ` Szabolcs Nagy
2020-05-21 13:16 ` Florian Weimer via Libc-alpha
2020-05-21 13:26 ` Szabolcs Nagy
2020-05-20 18:12 ` [PATCH 2/2] manual: Document __libc_single_threaded Florian Weimer via Libc-alpha
2020-05-21 7:52 ` Michael Kerrisk (man-pages) via Libc-alpha
2020-05-21 12:17 ` Florian Weimer via Libc-alpha
2020-05-21 11:18 ` Szabolcs Nagy
2020-05-21 12:16 ` Florian Weimer via Libc-alpha
2020-05-21 12:50 ` Adhemerval Zanella via Libc-alpha
2020-05-21 13:09 ` Szabolcs Nagy
2020-05-21 13:15 ` Adhemerval Zanella via Libc-alpha
2020-05-21 13:30 ` Szabolcs Nagy
2020-05-21 13:44 ` Florian Weimer via Libc-alpha
2020-05-21 13:58 ` Adhemerval Zanella via Libc-alpha
2020-05-21 14:03 ` Florian Weimer via Libc-alpha
2020-05-22 10:01 ` Szabolcs Nagy
2020-05-22 10:05 ` Florian Weimer via Libc-alpha
2020-05-22 10:54 ` Szabolcs Nagy
2020-05-22 11:08 ` Florian Weimer via Libc-alpha
2020-05-22 15:07 ` Rich Felker
2020-05-22 16:14 ` Rich Felker
2020-05-22 16:36 ` Adhemerval Zanella via Libc-alpha
2020-05-22 17:02 ` Florian Weimer via Libc-alpha
2020-05-22 17:18 ` Florian Weimer via Libc-alpha
2020-05-22 17:28 ` Rich Felker
2020-05-22 17:40 ` Florian Weimer via Libc-alpha
2020-05-22 17:49 ` Rich Felker [this message]
2020-05-22 19:22 ` Szabolcs Nagy
2020-05-22 19:53 ` Rich Felker
2020-05-23 6:49 ` Szabolcs Nagy
2020-05-23 16:02 ` Rich Felker
2020-05-25 8:08 ` Florian Weimer via Libc-alpha
2020-05-25 17:21 ` Rich Felker
2020-05-27 11:54 ` Florian Weimer via Libc-alpha
2020-05-27 15:36 ` Rich Felker
2020-06-03 15:00 ` Florian Weimer via Libc-alpha
2020-06-03 17:11 ` Rich Felker
2020-05-25 8:08 ` Florian Weimer via Libc-alpha
2020-05-21 13:56 ` Adhemerval Zanella via Libc-alpha
2020-05-21 13:14 ` Florian Weimer via Libc-alpha
2020-05-21 14:32 ` Adhemerval Zanella via Libc-alpha
2020-06-03 15:48 ` Florian Weimer via Libc-alpha
2020-06-03 17:52 ` Adhemerval Zanella via Libc-alpha
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
List information: https://www.gnu.org/software/libc/involved.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200522174932.GY1079@brightrain.aerifal.cx \
--to=dalias@libc.org \
--cc=fweimer@redhat.com \
--cc=libc-alpha@sourceware.org \
/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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).