>> Volatile prevents compiler optimization.
Where in your list code do you believe this is preventing a potential bug? There may be another solution that doesn't involve volatile.
gg
>> Volatile prevents compiler optimization.
Where in your list code do you believe this is preventing a potential bug? There may be another solution that doesn't involve volatile.
gg
Well, the prototypes on MS require them, so there's a compiler error if they are missing.Originally Posted by Codeplug
Volatile is not required by the GCC intrinsics, so I could as far as the compilers are concerned #define volatile and make it optional, or cast in the MS calls.
Note that this is not just about the list. All pointers which are targets for atomic operations are declared volatile.
I have understood (or rationalized, rather, since I don't know enough assembly to meaningfully inspect the output from the compiler, so I don't really know what it's doing) volatile to be required because the compiler is not taking the actions of other threads into account, and so would assume that the value in the pointer would only be changed by itself, when in fact other threads are also modifying the pointer.
Memory barriers and so on are also required for these cross-thread operations to work successfully, but I am thinking that without volatile, the compiler may end up (say) keeping a copy of a pointer value in a register for a long time (which might in principle mean forever, although it never would in practise), causing problems.
I may be wrong, but I think volatile may be necessary. The problem it addresses is the compiler optimizing a value into a register. I think when load barriers operate, copies of values already in registers are not modified; only the caches are affected. As such, the compiler can end up - in theory forever - using an earlier version of a value, never seeing it modified by load barriers. This will break most lock-free data structures.
I may be wrong, but I think taking a pointer to a non-volatile, casting that pointer to volatile and then accessing through the pointer is not supported by the Standard, but I think it is supported by modern GCCs. However, I'm not sure which versions, or what other compilers will do.
