Re: [PATCH][RFC] Remove volatile from data members in libstdc++

[Hans Boehm <Hans dot Boehm at hp dot com>]

This seems to be talking about atomicity w.r.t signals, not threads,
right?  In particular, it doesn't seem to mention alignment, and I don't
think loads that cross cache line or bus transaction boundaries are atomic
w.r.t threads running on different processors, though they would be atomic
w.r.t. signals.

At least historically glibc has supported ABIs that allow 16-bit default
alignment of 32-bit ints, as I recall?  (I think most M68K ABIs allowed
that by default, for example.  I don't know whether that applied to
multiprocessors.)

I also think that the applicable standards only make guarantees for
"volatile sig_atomic_t", not "sig_atomic_t", and those guarantees are only
with respect to signals.

Hans

On Fri, 14 Jul 2006, Joe Buck wrote:

> On Fri, Jul 14, 2006 at 05:00:53PM -0700, Boehm, Hans wrote:
> > Clearly, according to language standards, ordinary loads do not
> > guarantee atomicity.  A compiler that always load an int in two halves
> > is clearly standard conforming, according to current standards.
> > Hopefully you agree?
>
> No, this is incorrect on platforms that define the sig_atomic_t typedef
> as int, as many do.  See
>
> http://www.delorie.com/gnu/docs/glibc/libc_496.html
>
> "In practice, you can assume that int and other integer types no longer
> than int are atomic. You can also assume that pointer types are atomic;
> that is very convenient. Both of these assumptions are true on all of the
> machines that the GNU C library supports and on all POSIX systems we know
> of."
>
>