Re: Threadsafe copy of objective c object
Re: Threadsafe copy of objective c object
- Subject: Re: Threadsafe copy of objective c object
- From: David Duncan <email@hidden>
- Date: Tue, 03 Sep 2013 07:29:38 -0700
On Sep 3, 2013, at 5:39 AM, Jonathan Taylor <email@hidden> wrote:
> I would like to be able to take a copy of MyParameters from a thread that is not the main thread
Why?
Sure, you have a thread doing real-time video processing, but how expensive can it be to make a copy and send it over? Audio Units basically do this and they are just as real-time.
I think you may be over-optimizing or mis-optimizing given this requirement. The typical pattern for things like this is that you have an initial set of parameters, and then as they change you set updates that take effect as soon as the real-time pipeline can get to them.
> I am not sure how to do this in a fully correct manner. One might naively expect that designating properties as "atomic" could be sufficient. However I have read that "even atomic properties are not threadsafe" - although I was not able to establish the reason for this statement. Perhaps that statement only applies to more complex objects, in which case it may be I am worrying over nothing.
Atomic properties don’t guarantee thread-safety (of an object as a whole) but are threadsafe individually. The difference is this: Imagine you have an object with firstName and lastName writable properties, and a fullName derived property (appends lastName to firstName). Making the properties atomic ensures that you can safely set firstName and lastName from any thread, but does not ensure that fullName will always represent the result of a single thread’s work (assuming each thread sets both properties).
>
>
>>
>> Op 3 sep. 2013 om 13:16 heeft Lasse Jansen <email@hidden> het volgende geschreven:
>>
>>>> Since the implementation of -copy is up to you, you could just put @synchronized(self){…..} around the code in that method. That implements a lock which should make the copy thread-safe.
>>>
>>>
>>> No, it wouldn't. It would only ensure that two calls to copy are executed sequentially. You would need to add @synchronized(self) {…} to all other methods that modify the object too to ensure that the object isn't changed during a copy.
>>>
>>>
>>> Lasse
>>>
>>>
>>>
>>>
>>> Sent with Unibox
>>>
>>>
>>> _______________________________________________
>>>
>>> Cocoa-dev mailing list (email@hidden)
>>>
>>> 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:
>>>
>>> This email sent to email@hidden
>
>
> _______________________________________________
>
> Cocoa-dev mailing list (email@hidden)
>
> 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:
>
> This email sent to email@hidden
--
David Duncan
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden