I am trying to convert Java code into Objective C code. And the java code contains variables defined as volatile. I looked online and \"volatile\" usage in java as follwing<
Sharing mutable objects between different threads can be a big headache and cause bugs that are difficult to track down. Objective-c has a big preference towards immutable objects. I'd suggest that if possible, you find a way to pass around immutable objects instead if that is possible. Then you don't have to worry about a shared object being written to at all.
No, atomic
and volatile
are not the same thing.
atomic
(in a property declaration) means that the getter/setter will ensure that a whole value is get/set, regardless of what other threads might be doing simultaneously.
volatile
is an indicator to the compiler that a variable can be modified by other means (other threads, memory-mapped IO devices), so it should not optimize out (seemingly) unnecessary loads/stores of that variable. That's similar to what it means in Java, although Java adds some guarantees about memory barriers and ordering of reads and writes that C (and Objective-C) don't provide. In particular, in C, simply declaring a variable volatile
is not sufficient to safely use it from multiple threads wikipedia:volatile variable.
The volatile
keyword exists in Objective-C as well. You can use it.
This is because Objective-C is a superset of C.
Declaring the properties as atomic
will not correct what volatile
was meant to do. volatile
effectively tells the compiler not to optimize away checks done on that variable, because it may have changed when the compiler expected it to stay the same.
The simplest example is this. Say we have a global variable declared as:
int packetsReceived = 0;
And it's later used like this:
packetsRecieved = 0;
while (packetsRecieved < 10){
//Wait for more packets
}
processPackets();
We will never get through that loop, because the compiler will say "Hey, packetsRecieved
is never modified in that loop, therefore it will run infinitely." As a result, it will just make it a straight infinite loop so it can avoid having to check every time.
If we instead had declared the variable as:
volatile int packetsRecieved;
We are telling the compiler that this variable may change at any time, even when it looks like it should stay the same. So in our example, the machine code generated by the compiler will still have a check on the condition, and our program will work as expected.