2

Should i declare NSLock as atomic, or it's just a waste of time and the lock itself should be non atomic?

Zbun
  • 4,655
  • 3
  • 15
  • 27
  • Please clarify the use of the `NSLock` property. Is it used within the object only or is it designed to be "dished out" to other objects for their own use? – trojanfoe Jul 10 '14 at 09:37

3 Answers3

2

atomic makes setting and getting the property atomic, if the property doesn't need to be accessed atomically, maybe its only reads from multiple threads after if as been set, then it doesn't need to be atomic. Alternatively, how often is this property going to be called, you would need to call it pretty often in a loop to notice the effect of the property being atomic. you can also do things like call the property only once in a method and keep a local reference to it to reduce the overhead of it being atomic.

For properties, if there is any doubt I about whether it needs to be atomic or not, I usually make them atomic, if that creates a performance problem I can look at dealing with that later, but having a bug introduced because of a nonatomic property, is much more serious issue.

Nathan Day
  • 5,434
  • 2
  • 19
  • 39
0

Think about it. If you have a property that returns an NSLock, will the setter ever be called? Or would that be a horrendous bug that will make your app crash all over the place?

What you should do is have a look at @synchronized and figure out if that might not be a lot, lot easier to use than an NSLock.

gnasher729
  • 47,695
  • 5
  • 65
  • 91
  • No sure I understand this answer. Isn't `@synchronized` implemented using `NSLock` objects anyway? Please clarify. – trojanfoe Jul 10 '14 at 09:34
  • @synchronized is implemented in any way the compiler thinks is the best, which may be something similar to NSLock or not; unlikely to be an NSLock object. But why would you want to do work that the compiler can do for you? – gnasher729 Jul 10 '14 at 09:51
  • I understood from the question that this `NSLock` property was designed to be accessed from outside the object, otherwise why would it even be a property in the first place. Therefore `@synchronized` would not be a drop-in replacement. – trojanfoe Jul 10 '14 at 09:54
-1

Should i declare NSLock as atomic, or it's just a waste of time and the lock itself should be non atomic?

By default all properties in Objective-C are atomic. So no need to declare NSLock as atomic. And also it depends on your requirement whether you want to declare as non atomic, basically nonatomic attribute is used for multi threading purposes. If you have set the nonatomic attribute at the time of declaration, then any other thread wanting access to that object can access it and give results in respect to multi-threading.So it is faster as compared to atomic Refer this difference between atomic vs Non atomic

Community
  • 1
  • 1
Hussain Shabbir
  • 13,963
  • 4
  • 34
  • 53
  • Not sure that answers the question either. The problem is the question is unclear... – trojanfoe Jul 10 '14 at 09:41
  • It is very rare that using atomic solves multithreading issues, so best case it is just a waste of time, worst case it lulls you into a false belief of security. In this case, changing an NSLock object is bound to cause major problems. – gnasher729 Jul 10 '14 at 09:53
  • I have mentioned in the answer that no need to declare atomic. By default all properties are atomic – Hussain Shabbir Jul 10 '14 at 09:57
  • This does not answer the question. `atomic` has nothing to do with `property`. The `property` just happen to default to being `atomic` is not the answer to this question. – Pranay Aug 16 '19 at 15:51