Possible language changes

[Ben Hutchings]

Doug Lea wrote:
> Boehm, Hans wrote:
> > Atomicity is an interesting issue I had originally forgotten about.
> >  
> > - What happens if you store to a 32-bit volatile pointer on machines
> > with a 16-bit memory bus?  I think the Java answer is:
> >  
> > - If this is a uniprocessor, use your favorite uniprocessor atomicity
> > technique (probably some flavor of restartable atomic sections),
> > which can be pretty cheap.
> >  
> > - If this is a multiprocessor, get better hardware.
> 
> The same applies moving from 32 to 64 bits too. Plus there
> are some known tricks for some platforms. For example Java
> volatile longs turn out to be atomically storable using FIST
> on x86.
> 
> >  
> > Does this work here?
> 
> 
> Beats me. I think we need the advice of a C++-standards-weenie here.
> As Jim just posted about Ada, an Ada compiler can reject a
> program if target can't support it. But I don't think C++ has any
> kind of rules that look like that.

There's plenty of implementation-defined behaviour - including things
that affect well-formedness:

    template<int N> int get_const() { return N; }
    int (*getter)() = get_const<32768>; // ill-formed for 16-bit target

> In Java, we covered similar cases with atomics by allowing compilers to
> secretly use otherwise-inaccessible locks. But I bet that won't work in
> C++ because it changes sizeof's.
> 
> So I'm left not knowing.

In general C++ library facilities don't have to use the same built-in
types on every implementation; implementation differences can be
abstracted by type aliases.  So I was thinking the atomic operations
could be implemented by atomic_(whatever) functions or function
templates in std that would be implemented only for the suitable types.
One such type, preferably at least as wide as int, would be given the
type alias atomic_t (analogous to sig_atomic_t).  Then there would be a
type trait that indicates whether atomic operations are possible on any
particular type.

What concerns me more is the variation in the atomic operations that are
supported beyond read and write.  If I understood the documentation of
Hans Boehm's atomic-ops package correctly, HP-PA only supports TAS
(test-and-set) whereas I believe in general one would really want CAS
(or an equivalent using LL/SC) as a minimum for lock-free algorithms.
(I'm sure TAS is *sufficient*, but not *efficient* where CAS is also
available.)

> > What do volatile bit-fields mean?  I don't think the standards say?
> 
> How about: A member is volatile if any of its bit-fields are?

The words or other units that bitfields are packed into aren't members
in their own right, though, so it's unclear to me what this would mean.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice.
                                - John Levine, moderator of comp.compilers