On Sep 3, 2013, at 5:39 AM, Jonathan Taylor <jonathan.tay...@glasgow.ac.uk>
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 <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/david.duncan%40apple.com
>
> This email sent to david.dun...@apple.com
--
David Duncan
_______________________________________________
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
