0

My guess is that it would be similar with volatile keyword, which gives happened-before relation, visibility and atomic value assignment(in case of >32bit types as long) in Java. Is it?

(edit: my guess was that atomic attribute was similar to volatile, not nonatomic but turns out it wasn't anyway)

yhpark
  • 175
  • 1
  • 2
  • 9
  • Atomic/nonatomic in Objective-C applies to properties, something which Java does not explicitly have. The attributes control the synchronization that occurs in getter/setter methods for the properties. Both Java and Objective-C have "synchronized" attributes for code segments that mean roughly the same thing (mutual exclusion). I'm not offhand aware of something in Objective-C that has the same meaning as Java's "volatile" for variables, which affects the cache attributes of the variable. (But there are a lot of `__SOME_OPTION` options in Objective-C that I'm not up on.) – Hot Licks Mar 27 '14 at 00:14
  • And it should be noted that, in particular, "nonatomic" means basically "nothing". Not that it means nothing, but it means that the property is not to be synchronized in any way. – Hot Licks Mar 27 '14 at 00:25
  • I'm not sure what it means to have synchronized getter/setters if it's just plain old getter/setter. Java ensures out-of-thin-air safety applied to every 32bit operations(JCiP:3.1.2), and I'm sure Objective C has that level of safety. Then it should only makes sense to use `atomic` attribute if and only if I implement custom getter/setters. – yhpark Mar 27 '14 at 21:26
  • 1
    Note that Objective-C shares with C/C++ the ability to pass/assign elements larger than a single long/double/pointer. Assigning such an element is not guaranteed to be atomic without some "protection". – Hot Licks Mar 27 '14 at 22:57
  • That makes sense. I was thinking Java in which object assignment is always pointers. Moreover I'd also have to consider retain/release/... Thanks – yhpark Mar 27 '14 at 23:26

1 Answers1

0

"Atomic" in Objective C, according to this article, is similar to a synchronized variable in Java, such that it cannot be changed by two threads at the same time. nonatomic is the opposite, meaning a variable that is not synchronized, and therefore could be changed by multiple threads simultaneously.

Regarding volatile, according to wikipedia:

The Java programming language also has the volatile keyword, but it is used for a somewhat different purpose. When applied to a field, the Java volatile guarantees that:

  • (In all versions of Java) There is a global ordering on the reads and writes to a volatile variable. This implies that every thread accessing a volatile field will read its current value before continuing, instead of (potentially) using a cached value. (However, there is no guarantee about the relative ordering of volatile reads and writes with regular reads and writes, meaning that it's generally not a useful threading construct.)
  • (In Java 5 or later) Volatile reads and writes establish a happens-before relationship, much like acquiring and releasing a mutex.
  • Using volatile may be faster than a lock, but it will not work in some situations. The range of situations in which volatile is effective was expanded in Java 5; in particular, double-checked locking now works correctly.
Community
  • 1
  • 1
aliteralmind
  • 19,847
  • 17
  • 77
  • 108
  • As I commented in the question, what does it mean to have getter/setter synchronized if they're just plain getter/setters? 32bit operations such as assigning pointer or setting value to primitive 32bit variables should be atomic already. (assuming it's 32bit env) – yhpark Mar 27 '14 at 21:33
  • I'm honestly not sure of that answer. – aliteralmind Mar 27 '14 at 21:40