public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Torvald Riegel <triegel@redhat.com>
To: Rich Felker <dalias@aerifal.cx>
Cc: GLIBC Devel <libc-alpha@sourceware.org>,
	       libc-ports <libc-ports@sourceware.org>
Subject: Re: [PATCH] Unify pthread_once (bug 15215)
Date: Wed, 08 May 2013 20:47:00 -0000	[thread overview]
Message-ID: <1368046046.7774.1441.camel@triegel.csb> (raw)
In-Reply-To: <20130508175132.GB20323@brightrain.aerifal.cx>

On Wed, 2013-05-08 at 13:51 -0400, Rich Felker wrote:
> On Wed, May 08, 2013 at 04:43:57PM +0200, Torvald Riegel wrote:
> > Note that this will make a call to pthread_once that doesn't need to
> > actually run the init routine slightly slower due to the additional
> > acquire barrier.  If you're really concerned about this overhead, speak
> > up.  There are ways to avoid it, but it comes with additional complexity
> > and bookkeeping.
> 
> On the one hand, I think it should be avoided if at all possible.
> pthread_once is the correct, canonical way to do initialization (as
> opposed to hacks like library init functions or global ctors), and the
> main doubt lots of people have about doing it the correct way is that
> they're going to kill performance if they call pthread_once from every
> point where initialization needs to have been completed. If every call
> imposes memory synchronization, performance might become a real issue
> discouraging people from following best practices for library
> initialization.

Well, what we precisely need is that the initialization happens-before
(ie, the relation from the, say, C11 memory model) every call that does
not in fact initialize.  If initialization happened on another thread,
you need to synchronize.  But from there on, you are essentially free to
establish this in any way you want.  And there are ways, because
happens-before is more-or-less transitive.

> On the other hand, I don't think it's conforming to elide the barrier.
> POSIX states (XSH 4.11 Memory Synchronization):
> 
> "The pthread_once() function shall synchronize memory for the first
> call in each thread for a given pthread_once_t object."

No, it's not.  You could see just parts of the effects of the
initialization; potentially reading garbage can't be the intended
semantics :)

> Since it's impossible to track whether a call is the first call in a
> given thread

Are you sure about this? :)

> this means every call to pthread_once() is required to
> be a full memory barrier.

Note that we do not need a full memory barrier, just an acquire memory
barrier.  So this only matters on architectures with memory models that
give weaker per-default ordering guarantees.  For example, this doesn't
add any hardware barrier instructions on x86 or Sparc TSO.  But for
Power and ARM it does.

> I suspect this is unintended, and we should
> perhaps file a bug report with the Austin Group and see if the
> requirement can be relaxed.

I don't think that other semantics are intended.  If you return from
pthread_once(), initialization should have happened before that.  If it
doesn't, you don't really know whether initialization happened once, so
programs would be forced to do their own synchronization.


Torvald

  reply	other threads:[~2013-05-08 20:47 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-08 14:44 Torvald Riegel
2013-05-08 17:51 ` Rich Felker
2013-05-08 20:47   ` Torvald Riegel [this message]
2013-05-08 21:25     ` Rich Felker
2013-05-09  8:39       ` Torvald Riegel
2013-05-09 14:02         ` Rich Felker
2013-05-09 15:14           ` Torvald Riegel
2013-05-09 15:56             ` Rich Felker
2013-05-10  8:31               ` Torvald Riegel
2013-05-10 13:22                 ` Rich Felker
2013-05-23  4:15 ` Carlos O'Donell
2013-08-26 12:50   ` Ondřej Bílka
2013-08-26 16:45     ` Rich Felker
2013-08-26 18:41       ` Ondřej Bílka
2013-08-27  2:29         ` Rich Felker
2013-10-06  0:20   ` Torvald Riegel
2013-10-06 21:41     ` Torvald Riegel
2013-10-07 16:04     ` Joseph S. Myers
2013-10-07 21:53       ` Torvald Riegel
2014-03-31 11:44         ` Will Newton
2014-03-31 20:09           ` Torvald Riegel

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=1368046046.7774.1441.camel@triegel.csb \
    --to=triegel@redhat.com \
    --cc=dalias@aerifal.cx \
    --cc=libc-alpha@sourceware.org \
    --cc=libc-ports@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).