Thread: Casting away volatile

Your only option in C is the C-style cast.

Yes it should be safe to cast away the volatile qualifier on your pointers and C will allow you to do it as C is not particularly type-safe. A second thread can't change your pointers in a single-threaded app so it should be a safe type conversion.

From the C99 standard:

6.7.3:5 If an attempt is made to refer to an object defined with a volatile-qualified type through use of an lvalue with non-volatile-qualified type, the behavior is undefined.

From Wikipedia: Volatile_(computer_programming)

Despite being a common keyword, the behavior of volatile differs significantly between programming languages, and is easily misunderstood. In C and C++, it is a type qualifier, like const, and is a property of the type. Furthermore, in C and C++ it does not work in most threading scenarios, and that use is discouraged. In Java and C#, it is a property of a variable and indicates that the object to which the variable is bound may mutate, and is specifically intended for threading.

Whilst volatile was more for the days of interrupt handlers and for use where memory is shared across process boundaries, some interesting applications can arise in multithreaded code. It's main use is to stop optimisations reordering reads and writes to a memory location. This is C++ rather than C but it shows how the type qualifier can be useful to catch errors at compile time....
Volatile the multithreaded programmers best friend.
In C++ volatile is cast away sometimes once grabbing a critical section or a memory barrier. As in that section only one thread at a time can be running. It may well be undefined behaviour but it really ought to be a safe conversion. In this case the programmer knows more than the compiler which errs on the side of safety.

Originally Posted by Hobbit

Whilst volatile was more for the days of interrupt handlers and for use where memory is shared across process boundaries, some interesting applications can arise in multithreaded code. It's main use is to stop optimisations reordering reads and writes to a memory location. This is C++ rather than C but it shows how the type qualifier can be useful to catch errors at compile time....
Volatile the multithreaded programmers best friend.
In C++ volatile is cast away sometimes once grabbing a critical section or a memory barrier. As in that section only one thread at a time can be running. It may well be undefined behaviour but it really ought to be a safe conversion. In this case the programmer knows more than the compiler which errs on the side of safety.

I'm glad you were able to read and use my references. Do you see how that's better than just pulling an "answer" out of your ass? Still, until you prove it you're only assuming that the C++ example can be made to work in C.

C and C++ compilers treat volatile pointers the same way. Whilst strictly speaking it is undefined behaviour, that's just the standard erring on the side of safety. In this case the OP wants to use his code in a single-threaded environment where no other access to his pointers will be possible so optimisations can be allowed. Undefined or not it is safe to cast away volatile in this situation. It's simply an instruction to the compiler that says you can now cache this pointer in a register if the compiler sees that to be a sensible optimisation. Yes sure casting volatile away in a multithreaded application or where we are dealing with a memory mapped location can be deadly and shouldn't be done that is not the case here. The standard doesn't know what context the programmer wishes to cast away the volatile and so because in many situations it's not a good idea they left the behaviour undefined, but in this situation the programmer knows that there can be no other access to the pointer so the conversion is safe even though it is undefined behaviour. Strictly speaking LockingPtr relies on undefined behaviour yet it has been used in production code for more than 10 years until C++11 gave us a threading library and atomics.
I didn't use your references by the way. Wikis are hardly authoritative and can be edited by anyone. I have used LockingPtr myself for a decade without issue despite the fact that it is strictly speaking undefined behaviour. I try to read all articles by Alexandrescu, Sutter, and Meyers. They are among the world's foremost experts on the language I use most.
I was under the impression from the OP's post that he is a professional or decent amateur programmer who had profiled his code and seen the need to allow optimisations in this context. He certainly didn't appear to be a learner who I agree should be steered away from undefined behaviour. Of course the right answer is probably to rewrite the lock-free list so that it doesn't need to use volatile at all, but then it would probably no longer be lock-free.

Using InterlockedIncrement and family? They take a non-volatile pointer to volatile data.

Originally Posted by Hobbit

Using InterlockedIncrement and family? They take a non-volatile pointer to volatile data.

Yes. With the list, the pointers themselves are the volatile, as they have the atomic operations running on them, so I don't think I can get rid of them.

You can almost certainly, volatile is of limited use in C for multithreaded programming, it doesn't do anything for you except turn off optimisations, though there maybe times when that is necessary. In C++ as the article I linked shows you can force the type system to check race conditions at compile time which is very neat. You certainly don't need to send volatile pointers to the Interlocked*** family of functions. As said earlier you should be able to cast the volatile away in definitely single-threaded portions of code but be aware that is undefined behaviour although in practice it should work. For defined behaviour you'll have to rewrite the lock-free list to avoid the use of volatile.

Originally Posted by Hobbit

You can almost certainly, volatile is of limited use in C for multithreaded programming, it doesn't do anything for you except turn off optimisations, though there maybe times when that is necessary. In C++ as the article I linked shows you can force the type system to check race conditions at compile time which is very neat. You certainly don't need to send volatile pointers to the Interlocked*** family of functions.

Just to make sure we're on the same page - the variables which are being operated upon by the atomic operations are pointers themselves (and as such, being the targets for atomic operations, are volatile). The pointer to pointer (which is what I'm actually passing in to the Interlocked*() functions, as I need to give it the address of the volatile pointer) is non-volatile.

You probably don't need those pointers to be volatile. What's the lock-free strategy of your list? Compare and swap?

Originally Posted by Hobbit

You probably don't need those pointers to be volatile. What's the lock-free strategy of your list? Compare and swap?

Yes. Are there other methods?

I'm not sure, I tend to use lock-free structures that are tried and tested and weren't written by me. I've checked the source for my lock free structures this morning and it seems they all use multibyte compare and swap, and they use a preprocessor macro VOLATILE which is defined as an empty tag with a */ volatile /* and a note that it should be uncommented only on insane compilers. I think you should be able to remove the volatile throughout the lock-free list.