Since nobody was able to provide real answers to my questions, I wrote some 
dummy code to find out as much about that issue as possible.  Here are the 
results:

Remember, I listed the following cases:

>       a) retain
>       b) retain, nonatomic    
>       c) copy
>       d) copy, nonatomic      
>       e) assign
>       f) assign, nonatomic


And I gave sample code for a) and b) already:

> a) retain
> 
> - (id)value
> {
>       id res;
>       [_magic_lock lock];
>       res = [value retain];
>       [_magic_lock unlock];
>       return [res autorelease];
> }
> 
> - (void)setValue:(id)aNewValue
> {
>       [_magic_lock lock];
>       if (aNewValue != value) {
>               [value release];
>               value = [aNewValue retain];
>       }
>       [_magic_lock unlock];
> }
> 
> 
> b) retain, nonatomic
> 
> - (id)value
> {
>       return value;
> }
> 
> - (void)setValue:(id)aNewValue
> {
>       if (aNewValue != value) {
>               [value release];
>               value = [aNewValue retain];
>       }
> }

As far as my testing goes, the sample code seems to be pretty close to what's 
really going on, though Apple is probably doing all this stuff on a much lower 
level, possibly highly optimized and thus much faster than the code above ever 
could. Here's how the code for the other cases would look like:

c) copy

The getter equals case a)

- (void)setValue:(id)aNewValue
{
        [_magic_lock lock];
        if (aNewValue != value) {
                [value release];
                value = [aNewValue copy];
        }
        [_magic_lock unlock];
}


d) copy, nonatomic

The getter equals case b)

- (void)setValue:(id)aNewValue
{
        if (aNewValue != value) {
                [value release];
                value = [aNewValue copy];
        }
}


e) assign

- (id)value
{
        id res;
        [_magic_lock lock];
        res = value;
        [_magic_lock unlock];   
        return res;
}

- (void)setValue:(id)aNewValue
{
        [_magic_lock lock];
        value = aNewValue;
        [_magic_lock unlock];
}


f) assign, nonatomic

- (id)value
{
        return value;
}

- (void)setValue:(id)aNewValue
{
        value = aNewValue;
}


Apple may optimize case e) to become case f) in case reading/writing "value" is 
an atomic operation anyway, e.g. setting a 32 bit value on a 32 bit CPU is 
guaranteed to be atomic already through the compiler. However, setting a 64 bit 
value on a 32 bit CPU (or a 64 bit CPU running in 32 bit mode) is not atomic 
for example, just like setting a 8/16 bit value on a 32/64 bit CPU may not be 
atomic (this depends on CPU, e.g. some operations are atomic on Intel CPUs that 
used to be not atomic on PPC CPUs).

Kind regards,
Markus_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to