This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Unify pthread_once (bug 15215)
- From: Rich Felker <dalias at aerifal dot cx>
- To: Torvald Riegel <triegel at redhat dot com>
- Cc: GLIBC Devel <libc-alpha at sourceware dot org>, libc-ports <libc-ports at sourceware dot org>
- Date: Wed, 8 May 2013 13:51:32 -0400
- Subject: Re: [PATCH] Unify pthread_once (bug 15215)
- References: <1368024237 dot 7774 dot 794 dot camel at triegel dot csb>
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.
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."
Since it's impossible to track whether a call is the first call in a
given thread, this means every call to pthread_once() is required to
be a full memory barrier. 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.
Rich