Possible language changes

[Doug Lea]

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.

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.

>  
> 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?

-Doug