24

what's the auto-gen'd getter and setter look like for the following property value? 

... in .h
@interface MyClass : NSObject {
@private
    NSString *_value;
}

@property(retain) NSString *value;

... in .m
@synthesize value = _value;

what if I change the property to be

@property(retain, readonly) NSString *value;

specifically I am interested in the atomic part of the story, plus the retain, and if possible, detailed code would be more clear as to what's going exactly going on behind the scene.

JeremyP
  • 80,230
  • 15
  • 117
  • 158
tom
  • 13,143
  • 18
  • 63
  • 120
  • 1
    possible duplicate of [Atomic vs nonatomic properties](http://stackoverflow.com/questions/588866/atomic-vs-nonatomic-properties) – jscs Dec 05 '11 at 08:22

2 Answers2

24

They would look something like:

- (NSString*) value 
{
    @synchronized(self) {
        return [[_value retain] autorelease];
    }
}

- (void) setValue:(NSString*)aValue
{
    @synchronized(self) {
        [aValue retain];
        [_value release];
        _value = aValue;
    }
}

If you change the property to readonly, no setter is generated. The getter will be identical.

zpasternack
  • 17,494
  • 2
  • 59
  • 78
  • great! what if the property is @property (copy) NSString *value? – tom Dec 05 '11 at 08:28
  • 1
    Actually, I believe the setter would actually use the `if (aValue != value){ [aValue release] ; [value retain] ; value = aValue }` way of doing it. – JeremyP Dec 05 '11 at 09:22
  • 6
    Also - and this is more important - the lock is not the object's lock, but a lightweight lock just for the property. This means another method can't guarantee thread safety of the property by just synchronising on the object. – JeremyP Dec 05 '11 at 09:25
  • 5
    custom setter with @synchronized(self) is several factors slower than an atomic property's autosynthesized setter – LearnCocos2D Sep 24 '13 at 14:31
  • 1
    What would you recommend @LearnCocos2D? – W.K.S Nov 30 '13 at 13:03
  • 2
    @W.K.S: You can use `objc_getProperty` and `objc_setProperty` http://www.cocoawithlove.com/2009/10/memory-and-thread-safe-custom-property.html – user102008 Dec 22 '14 at 22:47
-3

if you do not specify the readonly with property declaration then Compiler will produce the getter and setter and be as below.

setter  ---> setValue:
[self setValue:@"setter"];

getter -----> Value,

NSString* myValue =  [self Value];

Compilar will not produce the setter function for the property which you have declared with readonly.

atomic are thread safe whereas nonatomic is not.

Jhaliya - Praveen Sharma
  • 31,294
  • 8
  • 69
  • 74
  • I am more interested in the atomic part of the story, and if there is a detailed code for that, that'll be more clear. I will update my question a bit for that. :-) – tom Dec 05 '11 at 08:24
  • 9
    Atomic properties are not thread-safe, they are atomic, hence the name. Being atomic is not the same as being thread-safe. Being atomic only means, that the system makes setting/getting a property value always works as getting/setting an `int` (which would usually not be the case for more complex data types). Since they are atomic, you can not "mash their values up" if you access them by multiple threads concurrently, but that's because they are atomic, not because they are thread-safe. – Mecki Jan 22 '13 at 14:01
  • 2
    Setting properties as atomic makes accessing them, be it for reading or writing, thread-safe. It does not ensure thread-safety in a class-wide context but is a tool to achieve it. – bompf Apr 11 '14 at 12:45