> One thing I was wondering—don't C11's atomics mostly supersede the use > of volatile for shared-memory and MMIO? Volatile's guarantees are > pretty weak and are only really sufficient for setjmp/longjmp and (in > POSIX) sig_atomic_t on modern architectures. Embedded toolchains may > of course have stronger platform-specific guarantees for volatile, but > the atomic operations would be more portable and generally useful.
Volatile and atomic are for two different purposes. Volatile is for declaring that variable access cannot be optimized away and atomic has to do with how the CPU accesses the variable. Atomic variables can still be moved around by the optimizer and optimized away, while a volatile variable cannot. Atomic is about accessing a value that could be concurrently manipulated. So I think they are sufficiently different use cases. Before C11/C++11 it was sometimes difficult to determine if variable access could be interrupted. In embedded programming, for instance, say you have a 16-bit memory bus and your accessing a 64-bit value. That would require 4 loads to access each part of the value. It is possible, if interrupts are enabled, for the CPU to switch to an interrupt handler between the loads, thus the 64-bit value may be wrong if it was manipulated in the interrupt handler. However, if the value you were accessing was only a 16-bit value, that can occur in 1 instruction that would not be interruptible. To fix this situation you can declare the variable to be atomic. In C++11 you can say: std::atomic<uint64_t> foo; And you can guarantee that access to foo are atomic. Really, most CPU's can load up to a double word in a single instruction, sometimes more. But for complex data structures they may have to break down the load into multiple operations and thats when atomic is important. Anyway, volatile is a different use case. Btw, I realized that clang/gcc allow you to say: `asm` and `asm volatile` to indicate whether or not to optimize the assembly instructions. -- John Harrison On May 4, 2012, at 2:09 PM, Joe Groff wrote: > On Fri, May 4, 2012 at 1:51 PM, John Harrison > <harr...@tigermail.auburn.edu> wrote: >> I know the llvm-ir has constructs for volatile but I was referring to any >> optimizations done above the llvm-ir, such as at the AST level. I am not >> sure what kinds of optimizations Rust currently does, so this might not be >> an issue. > > Good point. One of the core devs would be able to answer for sure, but > I think that by virtue of being an unsafe function operating on an > unsafe pointer, a volatile_load function should be an optimization > barrier relative to the value pointed to by the pointer. I don't think > the language can assume anything about the pointee after an unsafe > call. > > One thing I was wondering—don't C11's atomics mostly supersede the use > of volatile for shared-memory and MMIO? Volatile's guarantees are > pretty weak and are only really sufficient for setjmp/longjmp and (in > POSIX) sig_atomic_t on modern architectures. Embedded toolchains may > of course have stronger platform-specific guarantees for volatile, but > the atomic operations would be more portable and generally useful. > > -Joe > _______________________________________________ Rust-dev mailing list Rust-dev@mozilla.org https://mail.mozilla.org/listinfo/rust-dev
