This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: gcc 4.1 implements compiler builtins for atomic ops
On Sun, 2005-06-26 at 18:05 -0700, David S. Miller wrote:
> From: Ulrich Drepper <drepper@redhat.com>
> Date: Sun, 26 Jun 2005 17:50:16 -0700
>
> At the urging of another posting here, I read the GCC documentation on
> the builtins. And sadly, the GCC atomic builtin memory ordering
> semantics are very suboptimal. You don't need hard ordering if you
> just want a counter to update atomically, and you don't care what
> order other memory operations occur in wrt. that atomic operation.
Yes, that, and also these:
type __sync_lock_test_and_set (type *ptr, type value, ...)
void __sync_lock_release (type *ptr, ...)
It is obvious to me that people will use them to implement spinlocks,
and that is totally broken. There are even more issues with atomics used
as locks that atomics alone, for example, loops of ldarx on ppc can
livelock on some CPUs, SMT (==HT) CPUs wants a thread to "relax" when
spinning on a lock (same with shared processor on virtual environments,
that includes things like xen and thus isn't specific to ppc), and
more ...
Unfortunately, I'm afraid that my influence on gcc folks is about close
to 0 and since this is already in gcc CVS, I am fighting a lost battle.
userland apps will be full of a new funny generation of bugs due to that
and we'll have to cope with it =P
Ben.