Re: Threadsafe copy of objective c object
On 4 Sep 2013, at 16:46, Marcel Weiher wrote: Unless there is some dire reason not to do this, I would make a copy on the main thread every time the UI changes, and stash that copy somewhere the worker thread can access it easily. That's a really good plan, I realised that last night. I had been stuck thinking about kind of the opposite approach (make a copy on each invocation of the processing algorithm), but this makes a lot of sense. How does this sound: When the UI leads to changes in the (mutable) primary object I'll make a copy stored in an immutable shadow object (from the main thread). Whenever the algorithm is invoked (from a secondary thread in response to receipt of a frame) I retain the immutable shadow object and pass this pointer to the algorithm. Sounds pretty good to me. I’d probably stash it in an instance variable. In a sense, this is a variant of the immutability that Ian and Jens suggested: create a copy that you won’t mutate. OK, thanks everyone for your input on this one. I've got something I'm fairly happy with now, which is working according to plan. I was a bit surprised at how much glue I ended up having to put together to make it work though. Maybe that's just the nature of the thing, but if anybody was interested enough to critique the code that I've come up with (on or off list) then I'd be very grateful to hear any comments. https://docs.google.com/file/d/0Bye8FKbpg3dYa1R2Z1hPWERmcjQ/edit Cheers Jonny. ___ 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
Re: Threadsafe copy of objective c object
On Sep 3, 2013, at 12:52 , Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
I have an objective c object which contains a number of properties that serve
as parameters for an algorithm. They are bound to UI elements. I would like
to take a snapshot copy of the object that will be used for one whole run of
the algorithm (rather than risk parameters changing halfway through the run).
i.e. I just want to do [myObject copy].
What are the property parameters? A bunch of numbers, maybe some strings?
[complications]
Is there any way, then, that I can take a copy in a threadsafe manner? If
necessary I can do the copy on the main thread, but I would prefer not to
have to do that for timing reasons.
Unless there is some dire reason not to do this, I would make a copy on the
main thread every time the UI changes, and stash that copy somewhere the worker
thread can access it easily.
The reasoning is that humans are generally slow compared to computers, so
changes are likely going to happen at reasonably slow rate.
-(void)uiDidChange
{
id newSnapshot=[[parameters copy] autorelease];
[self setSnapshot:newSnapshot];
}
Marcel
___
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
Re: Threadsafe copy of objective c object
Thanks to everyone who has chimed in on this one - you've all been really helpful. Looks like some conclusions are emerging; some selected replies below. On 3 Sep 2013, at 20:21, Tom Davie tom.da...@gmail.com wrote: Remove the mutation methods. Make your object immutable, the referential transparency will give you “free” parallelism. If you want a mutated version of the object, create a new object. Very good suggestion, though unfortunately my use of UI bindings rather scuppers that one. Otherwise it could be an ideal solution On 3 Sep 2013, at 19:49, Marcel Weiher marcel.wei...@gmail.com wrote: What are the property parameters? A bunch of numbers, maybe some strings? Yep. Unless there is some dire reason not to do this, I would make a copy on the main thread every time the UI changes, and stash that copy somewhere the worker thread can access it easily. That's a really good plan, I realised that last night. I had been stuck thinking about kind of the opposite approach (make a copy on each invocation of the processing algorithm), but this makes a lot of sense. How does this sound: When the UI leads to changes in the (mutable) primary object I'll make a copy stored in an immutable shadow object (from the main thread). Whenever the algorithm is invoked (from a secondary thread in response to receipt of a frame) I retain the immutable shadow object and pass this pointer to the algorithm. From what Jens and others have said, it's my understanding that if the property for the (immutable) shadow object is designated atomic/retain then I wouldn't need a mutex to access it. On 3 Sep 2013, at 18:37, Jens Alfke j...@mooseyard.com wrote: This is one reason why concurrent programming often relies on immutable objects — because they can be passed around multiple threads safely. Thread-safe access to mutable objects is a real pain and it’s very easy to create subtle bugs that only show up very rarely. Wise words that I had rather lost sight of! I was too focused on incremental changes to the original (poor) design... On 3 Sep 2013, at 18:26, Kyle Sluder k...@ksluder.com wrote: One of the cardinal rules of Audio Units is Thou Shalt Not Allocate Memory On The Render Callback Thread. malloc takes a lock. Taking a lock is a great way to make you thread miss its hard-realtime constraint, which leads to glitching and potentially getting killed by the host. Yes, I learned that one the hard way a while back! ___ 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
Re: Threadsafe copy of objective c object
On Sep 4, 2013, at 10:56 , Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote: On 3 Sep 2013, at 19:49, Marcel Weiher marcel.wei...@gmail.com wrote: Unless there is some dire reason not to do this, I would make a copy on the main thread every time the UI changes, and stash that copy somewhere the worker thread can access it easily. That's a really good plan, I realised that last night. I had been stuck thinking about kind of the opposite approach (make a copy on each invocation of the processing algorithm), but this makes a lot of sense. How does this sound: When the UI leads to changes in the (mutable) primary object I'll make a copy stored in an immutable shadow object (from the main thread). Whenever the algorithm is invoked (from a secondary thread in response to receipt of a frame) I retain the immutable shadow object and pass this pointer to the algorithm. Sounds pretty good to me. I’d probably stash it in an instance variable. In a sense, this is a variant of the immutability that Ian and Jens suggested: create a copy that you won’t mutate. From what Jens and others have said, it's my understanding that if the property for the (immutable) shadow object is designated atomic/retain then I wouldn't need a mutex to access it. Yep. Marcel ___ 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
Threadsafe copy of objective c object
This feels like it should be a very basic question, but it's not one I've managed to find an answer to - can somebody here advise? I have an objective c object which contains a number of properties that serve as parameters for an algorithm. They are bound to UI elements. I would like to take a snapshot copy of the object that will be used for one whole run of the algorithm (rather than risk parameters changing halfway through the run). i.e. I just want to do [myObject copy]. The complication is in ensuring this is threadsafe: ideally I would like to make the copy on a thread other than the main thread. My understanding is that properties themselves, even when designated atomic, are in some way not fully threadsafe, although I haven't found a clear explanation of exactly what makes them unsafe. I don't know if the 'copy' method is threadsafe or not, I am inclined to suspect not. Is there any way, then, that I can take a copy in a threadsafe manner? If necessary I can do the copy on the main thread, but I would prefer not to have to do that for timing reasons. Any suggestions? Cheers Jonny. ___ 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
Re: Threadsafe copy of objective c object
On 03/09/2013, at 12:52 PM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
Is there any way, then, that I can take a copy in a threadsafe manner? If
necessary I can do the copy on the main thread, but I would prefer not to
have to do that for timing reasons. Any suggestions?
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.
--Graham
___
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
Re: Threadsafe copy of objective c object
Ah, that's a good point about implementing -copy myself. However, how would
@synchronized(self){…..} help there? Surely all that would do is prevent
multiple threads from calling 'copy' simultaneously - which as far as I am
aware isn't something I should be worried about. My understanding is that it
would have no impact on whether for example the copied object contains correct
values.
If it's relevant, I should add that the object's properties are all simple
types (double, int, bool etc).
It doesn't help that I'm not really sure what window conditions I am guarding
against in my desire for thread safety, which makes my question a little vague.
I guess that what I would like is the following:
- [myObject copy] will not crash/raise exceptions/etc when called from a
thread other than the main thread
- [myObject copy] returns a copy in which all parameters are 'valid'
(i.e. an individual parameter is either the 'old' or the 'new' value in the
case where the object is being changed at the time of the copy)
- True thread safety would require a copy that represents an
instantaneous snapshot of the state of the entire object, i.e. copy not taken
while object is being updated. Actually, I suspect this last condition is not a
problem for my specific case, but best to be on the safe side, for several
different reasons.
On 3 Sep 2013, at 12:04, Graham Cox wrote:
On 03/09/2013, at 12:52 PM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
Is there any way, then, that I can take a copy in a threadsafe manner? If
necessary I can do the copy on the main thread, but I would prefer not to
have to do that for timing reasons. Any suggestions?
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.
--Graham
___
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
Re: Threadsafe copy of objective c object
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/archive%40mail-archive.com
This email sent to arch...@mail-archive.com
Re: Threadsafe copy of objective c object
Hi,
Basically you are trying to protect the values of an object while you are
copying.
If this is the case, then wherever you access these properties you will be need
to use a lock based on the object you are copying.
In order to do this, you need to lock the whole object whenever you are
accessing the values, one way of doing this is to do something like this:
SafeObj*myCurrentObject;//Assume set to object
you wish to copy.
SafeObj*myNewObject;
//**
//** Read Values
//**
myNewObject = [[SafeObj alloc] initWithObject: myCurrentObject];
Then in initWithObject, do this:
- (id) initWithObject:(SafeObj*) theObject;
{
self = [self init];
if (self == nil)
return nil;
@sychronized(theObject)
{
self.pVal1 =theObject.pVal1;
self.pVal2 =[theObject.pVal2 copy];
self.pVal3 =[theObject.pVal2 mutableCopy];
}
return self;
}
Of course, in the rest of the code that accesses pValX, you'd need to add
@synchronized around getting and setting them. The properties obviously need to
be protected as a set, so to read them, create a new local object using
initWithObject to copy the values.
To write to a set, you need to add another method:
-(void) setValuesFromObject::(SafeObj*) theObject;
{
@sychronized(self)
{
self.pVal1 =theObject.pVal1;
self.pVal2 =[theObject.pVal2 copy];
self.pVal3 =[theObject.pVal2 mutableCopy];
}
}
So, to increment pVal1, you'd do this:
SafeObj*myCurrentObject;//Assume set to object
you wish to copy.
SafeObj*myNewObject;
//**
//** Read Values
//**
myNewObject = [[SafeObj alloc] initWithObject: myCurrentObject];
myNewObject.pVal1++;
[self setValuesFromObject: myNewObject];
Hope this helps
Dave
On 3 Sep 2013, at 11:52, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote:
This feels like it should be a very basic question, but it's not one I've
managed to find an answer to - can somebody here advise?
I have an objective c object which contains a number of properties that serve
as parameters for an algorithm. They are bound to UI elements. I would like
to take a snapshot copy of the object that will be used for one whole run of
the algorithm (rather than risk parameters changing halfway through the run).
i.e. I just want to do [myObject copy].
The complication is in ensuring this is threadsafe: ideally I would like to
make the copy on a thread other than the main thread. My understanding is
that properties themselves, even when designated atomic, are in some way not
fully threadsafe, although I haven't found a clear explanation of exactly
what makes them unsafe. I don't know if the 'copy' method is threadsafe or
not, I am inclined to suspect not.
Is there any way, then, that I can take a copy in a threadsafe manner? If
necessary I can do the copy on the main thread, but I would prefer not to
have to do that for timing reasons. Any suggestions?
Cheers
Jonny.
___
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
Re: Threadsafe copy of objective c object
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?
Verstuurd vanaf mijn iPhone
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
Re: Threadsafe copy of objective c object
On 03/09/2013, at 1:23 PM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk
wrote:
Ah, that's a good point about implementing -copy myself. However, how would
@synchronized(self){…..} help there? Surely all that would do is prevent
multiple threads from calling 'copy' simultaneously - which as far as I am
aware isn't something I should be worried about. My understanding is that it
would have no impact on whether for example the copied object contains
correct values.
It wasn't really clear from your post where it needs to be thread safe. It
sounded as though you wanted to call copy on the original object from
multiple threads. As Lasse pointed out, that's not enough if the copied values
can be changed.
If it's relevant, I should add that the object's properties are all simple
types (double, int, bool etc).
If they are declared as atomic, I believe you can trust that simple types are
thread safe. It's when they are objects that things can still mutate mid-way
through a setter.
It doesn't help that I'm not really sure what window conditions I am guarding
against in my desire for thread safety, which makes my question a little
vague.
Well, indeed.
If you are making a copy of the object for the purpose of passing it as a set
of parameters to some other code, then presumably that object, once copied, is
self-contained and is used on a single thread from then on. That was the
scenario I sort of assumed from your original post. If that's not the case then
you need to make the problem clearer, i.e. is the algorithm multi-threaded in
itself?
--Graham
___
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
Re: Threadsafe copy of objective c object
On 9/3/13 1:23 PM, Jonathan Taylor wrote: - True thread safety would require a copy that represents an instantaneous snapshot of the state of the entire object, i.e. copy not taken while object is being updated. Actually, I suspect this last condition is not a problem for my specific case, but best to be on the safe side, for several different reasons. That means you have to make the copy and write accesses to the individual properties mutually exclusive. Depending on the number of properties in your object, it might be easier to completely exchange the object whenever you want to mutate one if its properties, basically treating the whole object immutable. Copying is trivial then. Of course it depends on how many times a second you need to change properties. Regards Markus -- __ Markus Spoettl ___ 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
Re: Threadsafe copy of objective c object
Opps! Typeo, should read: [myCurrentObject setValuesFromObject: myNewObject]; Dave On 3 Sep 2013, at 11:52, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote: This feels like it should be a very basic question, but it's not one I've managed to find an answer to - can somebody here advise? I have an objective c object which contains a number of properties that serve as parameters for an algorithm. They are bound to UI elements. I would like to take a snapshot copy of the object that will be used for one whole run of the algorithm (rather than risk parameters changing halfway through the run). i.e. I just want to do [myObject copy]. The complication is in ensuring this is threadsafe: ideally I would like to make the copy on a thread other than the main thread. My understanding is that properties themselves, even when designated atomic, are in some way not fully threadsafe, although I haven't found a clear explanation of exactly what makes them unsafe. I don't know if the 'copy' method is threadsafe or not, I am inclined to suspect not. Is there any way, then, that I can take a copy in a threadsafe manner? If necessary I can do the copy on the main thread, but I would prefer not to have to do that for timing reasons. Any suggestions? Cheers Jonny. ___ 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/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
Re: Threadsafe copy of objective c object
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
Re: Threadsafe copy of objective c object
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
Re: Threadsafe copy of objective c object
On Tue, Sep 3, 2013 at 2:39 PM, Jonathan Taylor
jonathan.tay...@glasgow.ac.uk wrote:
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.
1. Create MyParameters instance on some object on the main thread and call
it mainParameters for example.
2. All values are UI related, so, fill them on the main thread. But lock
your mainParameters object before. So, on the main thread do this ...
@synchronized( myObjectHoldingMyParameters.mainParameters ) {
myObjectHoldingMyParameters.mainParameters.X = X;
...
}
3. When you do want a copy on any other thread, do this ...
MyParamaters *paramsCopy;
@synchronized( myObjectHoldingMyParameters.mainParameters ) {
paramsCopy = [myObjectHoldingMyParameters.mainParameters copy];
}
... and implement deep copy without locking. It's done via @synchronized.
___
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
Re: Threadsafe copy of objective c object
All sounds nice, except for the fact that the parameters are being changed
behind the scenes via the binding system. So I think I may have to implement
locking on every (explicitly implemented) get/set method. That was what I had
been rather hoping to avoid, but it sounds from what people are saying as if
that's what I may have to do...
On 3 Sep 2013, at 13:54, Robert Vojta wrote:
On Tue, Sep 3, 2013 at 2:39 PM, Jonathan Taylor
jonathan.tay...@glasgow.ac.uk wrote:
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.
1. Create MyParameters instance on some object on the main thread and call it
mainParameters for example.
2. All values are UI related, so, fill them on the main thread. But lock your
mainParameters object before. So, on the main thread do this ...
@synchronized( myObjectHoldingMyParameters.mainParameters ) {
myObjectHoldingMyParameters.mainParameters.X = X;
...
}
3. When you do want a copy on any other thread, do this ...
MyParamaters *paramsCopy;
@synchronized( myObjectHoldingMyParameters.mainParameters ) {
paramsCopy = [myObjectHoldingMyParameters.mainParameters copy];
}
... and implement deep copy without locking. It's done via @synchronized.
___
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
Re: Threadsafe copy of objective c object
Then this should be enough ...
- (MyParameters *)copyParameters {
__block MyParameters *parameters;
dispatch_sync( dispatch_get_main_queue(), ^{
parameters = [myObjectHoldingParameters.parameters copy];
});
return parameters;
}
... if all your parameters object properties are set on the main thread
only.
___
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
Re: Threadsafe copy of objective c object
Ah. In my original email I didn't explain *why* it is that ideally I would
like to make the copy on a thread other than the main thread. The algorithm is
doing real-time video processing, and I very much want to avoid holding up
anything in that code path by synchronizing with the main queue. Past
experience has shown that that does lead to glitches I am keen to avoid. So,
while I'm a big fan of such constructions, I'm deliberately trying to avoid
that here.
Serializing access to MyParameters will work, it's just a shame that there
isn't such a tidy way of achieving that...
On 3 Sep 2013, at 14:18, Robert Vojta wrote:
Then this should be enough ...
- (MyParameters *)copyParameters {
__block MyParameters *parameters;
dispatch_sync( dispatch_get_main_queue(), ^{
parameters = [myObjectHoldingParameters.parameters copy];
});
return parameters;
}
... if all your parameters object properties are set on the main thread only.
___
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
Re: Threadsafe copy of objective c object
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
Re: Threadsafe copy of objective c object
You could use a dedicated dispatch queue for all property access and use
dispatch barriers to restrict access to the queue for writes, while still
allowing simultaneous reads.
In -copy:
- (id)copy
{
__block __typeof(self) copy;
dispatch_async(self.propertyQueue, ^{
copy = [[[self class] alloc] init];
// Copy properties here
});
return copy;
}
This assumes a property called propertyQueue:
@property (readonly, nonatomic) dispatch_queue_t propertyQueue;
- (dispatch_queue_t)propertyQueue
{
if (!_propertyQueue) {
_propertyQueue = dispatch_queue_create(queue name here,
DISPATCH_QUEUE_CONCURRENT);
}
return _propertyQueue;
}
In your property getters:
- (int)count
{
__block int count;
dispatch_async(self.propertyQueue, ^{
count = _count;
});
return count;
}
And finally, in your property *setters*:
- (void)setCount:(int)count
{
dispatch_barrier_async(self.propertyQueue, ^{
_count = count;
});
}
Hope this helps!
(Note: all code was typed in the e-mail, so may not compile.)
Jeff Kelley
On Tue, Sep 3, 2013 at 9:34 AM, Jonathan Taylor
jonathan.tay...@glasgow.ac.uk wrote:
Ah. In my original email I didn't explain *why* it is that ideally I
would like to make the copy on a thread other than the main thread. The
algorithm is doing real-time video processing, and I very much want to
avoid holding up anything in that code path by synchronizing with the main
queue. Past experience has shown that that does lead to glitches I am keen
to avoid. So, while I'm a big fan of such constructions, I'm deliberately
trying to avoid that here.
Serializing access to MyParameters will work, it's just a shame that there
isn't such a tidy way of achieving that...
On 3 Sep 2013, at 14:18, Robert Vojta wrote:
Then this should be enough ...
- (MyParameters *)copyParameters {
__block MyParameters *parameters;
dispatch_sync( dispatch_get_main_queue(), ^{
parameters = [myObjectHoldingParameters.parameters copy];
});
return parameters;
}
... if all your parameters object properties are set on the main thread
only.
___
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/slaunchaman%40gmail.com
This email sent to slauncha...@gmail.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
Re: Threadsafe copy of objective c object
On Tue, Sep 3, 2013, at 11:32 AM, Jeff Kelley wrote: Ken is, of course, correct. This is what I get for writing it in my mail client. You’ll want to use dispatch_sync() for reads and dispatch_barrier_async() for writes. …thus defeating the purpose of moving the copy to another thread. --Kyle Sluder ___ 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
Re: Threadsafe copy of objective c object
What I’m surprised no on has mentioned here is the trivial… Remove the mutation methods. Make your object immutable, the referential transparency will give you “free” parallelism. If you want a mutated version of the object, create a new object. Tom Davie ___ 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
Re: Threadsafe copy of objective c object
On Tue, Sep 3, 2013, at 07:29 AM, David Duncan wrote: 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. One of the cardinal rules of Audio Units is Thou Shalt Not Allocate Memory On The Render Callback Thread. malloc takes a lock. Taking a lock is a great way to make you thread miss its hard-realtime constraint, which leads to glitching and potentially getting killed by the host. The typical way to do this is to perform your allocations and copies on a NON-realtime thread, and transfer ownership of data to your render thread via a lockless data structure such as a ring buffer. Your realtime thread runs for very brief periods, consuming one or two chunks of data, while your non-realtime thread runs more sporadically but for much longer periods of time, hopefully often enough to keep up with the realtime thread's consumption of data. --Kyle Sluder ___ 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
Re: Threadsafe copy of objective c object
On Sep 3, 2013, at 9:26 AM, Jeff Kelley wrote:
You could use a dedicated dispatch queue for all property access and use
dispatch barriers to restrict access to the queue for writes, while still
allowing simultaneous reads.
In -copy:
- (id)copy
{
__block __typeof(self) copy;
dispatch_async(self.propertyQueue, ^{
You can't use dispatch_async() for this. It has to be synchronous, since
you're returning the value that's going to be set.
copy = [[[self class] alloc] init];
// Copy properties here
});
return copy;
}
This assumes a property called propertyQueue:
@property (readonly, nonatomic) dispatch_queue_t propertyQueue;
- (dispatch_queue_t)propertyQueue
{
if (!_propertyQueue) {
_propertyQueue = dispatch_queue_create(queue name here,
DISPATCH_QUEUE_CONCURRENT);
}
return _propertyQueue;
}
In your property getters:
- (int)count
{
__block int count;
dispatch_async(self.propertyQueue, ^{
Same here.
count = _count;
});
return count;
}
And finally, in your property *setters*:
- (void)setCount:(int)count
{
dispatch_barrier_async(self.propertyQueue, ^{
_count = count;
});
}
Regards,
Ken
___
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
Re: Threadsafe copy of objective c object
Ken is, of course, correct. This is what I get for writing it in my mail
client.
You’ll want to use dispatch_sync() for reads and dispatch_barrier_async()
for writes.
Jeff Kelley
On Tue, Sep 3, 2013 at 2:30 PM, Ken Thomases k...@codeweavers.com wrote:
On Sep 3, 2013, at 9:26 AM, Jeff Kelley wrote:
You could use a dedicated dispatch queue for all property access and use
dispatch barriers to restrict access to the queue for writes, while still
allowing simultaneous reads.
In -copy:
- (id)copy
{
__block __typeof(self) copy;
dispatch_async(self.propertyQueue, ^{
You can't use dispatch_async() for this. It has to be synchronous, since
you're returning the value that's going to be set.
copy = [[[self class] alloc] init];
// Copy properties here
});
return copy;
}
This assumes a property called propertyQueue:
@property (readonly, nonatomic) dispatch_queue_t propertyQueue;
- (dispatch_queue_t)propertyQueue
{
if (!_propertyQueue) {
_propertyQueue = dispatch_queue_create(queue name here,
DISPATCH_QUEUE_CONCURRENT);
}
return _propertyQueue;
}
In your property getters:
- (int)count
{
__block int count;
dispatch_async(self.propertyQueue, ^{
Same here.
count = _count;
});
return count;
}
And finally, in your property *setters*:
- (void)setCount:(int)count
{
dispatch_barrier_async(self.propertyQueue, ^{
_count = count;
});
}
Regards,
Ken
___
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
Re: Threadsafe copy of objective c object
On Sep 3, 2013, at 3:52 AM, Jonathan Taylor jonathan.tay...@glasgow.ac.uk wrote: The complication is in ensuring this is threadsafe: ideally I would like to make the copy on a thread other than the main thread. My understanding is that properties themselves, even when designated atomic, are in some way not fully threadsafe, although I haven't found a clear explanation of exactly what makes them unsafe. This doesn’t have anything to do with atomic properties — all that keyword does is ensure that the property’s synthesized accessor methods are thread-safe with respect to the property value. It doesn’t help at all if you’re considering the object as a whole — you can access property a and then property b and get valid values for both, but they might not be consistent with each other because they were accessed at different times. If you want to look at the object as a whole you have to use some higher-level locking to keep it from being mutated while you work on it. I don't know if the 'copy' method is threadsafe or not, I am inclined to suspect not. No, you’re responsible for implementing -copy yourself. The base implementation in NSObject doesn’t copy any fields or properties implemented in subclasses. Is there any way, then, that I can take a copy in a threadsafe manner? If the object is mutable, you have to synchronize every method that can alter its state, probably using @synchronized(self). This means you can’t use synthesized property setters. Then synchronize the copy method the same way. This is one reason why concurrent programming often relies on immutable objects — because they can be passed around multiple threads safely. Thread-safe access to mutable objects is a real pain and it’s very easy to create subtle bugs that only show up very rarely. —Jens smime.p7s Description: S/MIME cryptographic signature ___ 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
