On 3 Sep 2013, at 13:39, Jonathan Taylor <jonathan.tay...@glasgow.ac.uk> 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 <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/dave%40looktowindward.com
>
> This email sent to d...@looktowindward.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
