This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Transition to C11 atomics and memory model
- From: Torvald Riegel <triegel at redhat dot com>
- To: GLIBC Devel <libc-alpha at sourceware dot org>
- Date: Wed, 17 Sep 2014 15:57:10 +0200
- Subject: Re: Transition to C11 atomics and memory model
- Authentication-results: sourceware.org; auth=none
- References: <1410719669 dot 4967 dot 160 dot camel at triegel dot csb> <1410904080 dot 4967 dot 400 dot camel at triegel dot csb>
On Tue, 2014-09-16 at 23:48 +0200, Torvald Riegel wrote:
> * Membars not being defined on i486 and x86_64 (unless I missed
> something). The HW memory model for these two is TSO, which would mean
> that algorithms that rely on atomic_full_barrier won't work. I'm not
> sure whether we have these in current code, but atomic_full_barrier is
> used in code I'm working on.
Based on a quick look at uses of atomic_full_barrier, this doesn't seem
to cause incorrect behavior *currently*:
* nptl/pthread_mutex_setprioceiling.c has a full barrier immediately
followed by a futex syscall, which is a full barrier too effectively.
* sysdeps/nptl/fork.c seems to only need an acquire barrier, so on x86
the current compiler-only barrier that the full barrier will result in
is sufficient.
* Other generic code that uses full barriers (eg, sem_post) currently
has custom asm versions on x86/x86_64. However, once we remove those,
the lack of a correct full barrier will be a bug.
To summarize, I think we need to fix the full barriers as soon as we add
other code that uses atomic_full_barrier and is used by x86/x86_64.
This is #17403.