> 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.
>
> Op 3 sep. 2013 om 13:16 heeft Lasse Jansen <la...@lasselog.com> 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 (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:
>> https://lists.apple.com/mailman/options/cocoa-dev/diederik%40tenhorses.com
>>
>> This email sent to diede...@tenhorses.com
_______________________________________________
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:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
