Re: Threadsafe copy of objective c object
Re: Threadsafe copy of objective c object
- Subject: Re: Threadsafe copy of objective c object
- From: Dave <email@hidden>
- Date: Tue, 03 Sep 2013 13:53:46 +0100
On 3 Sep 2013, at 13:39, Jonathan Taylor <email@hidden> wrote:
>> Is it possible to reverse the issue? Keep the original object (living on the main thread) untouched, make a copy for algorithm processing as an async task, then, when done, update the original object from the copy that may have been changed during async processing? Or will that cause the exact same problem in the final step?
>
> Things are simpler than that I think - the object containing the parameters won't be changed by running the algorithm. The copy that I want to take will be treated as read-only.
>
> To recap/expand:
>
> The primary instance of the object (call it MyParameters) is bound to UI elements. Changes to the UI will change the values of its properties (int/bool/double). These changes will take place on the main thread.
>
> I would like to be able to take a copy of MyParameters from a thread that is not the main thread, and have that copy be a non-corrupted snapshot of the primary instance of MyParameters. The copy will not be altered; no changes need to be propagated back to the primary instance. Indeed, the motivation behind my question is the *requirement* that this copy does not change in any way (despite the primary instance possibly changing).
>
> 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.
Do the values have to be taken as a set? e.g. If you had pVal1, pVal2, pVal3, and while copying pVal2 gets changed. You can lock individual properties with atomic, BUT if they are to be treated as a set, then one thread could be writing to pVal2 while another thread is reading from pVal1.
If this is the case, then you need to lock the whole copy process as per my last post
Cheers
Dave
>
>>
>> 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
_______________________________________________
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