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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
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
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
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
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.
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
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]
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.
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
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
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;
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
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,
27 matches
Mail list logo
