On Sep 3, 2013, at 12:52 , Jonathan Taylor
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
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
On Sep 4, 2013, at 10:56 , Jonathan Taylor
wrote:
> On 3 Sep 2013, at 19:49, 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.
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 wrote:
> Remove the mutation methods. Make your object immutable, the referential
> transparency will giv
On Sep 3, 2013, at 3:52 AM, Jonathan Taylor
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
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 wrote:
> On Sep 3, 2013, at 9:26 AM, Jeff Kelley wrote:
>
> > You cou
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;
>
On Tue, Sep 3, 2013, at 07:29 AM, David Duncan wrote:
> On Sep 3, 2013, at 5:39 AM, Jonathan Taylor
> 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
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 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.
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 Sep 3, 2013, at 5:39 AM, Jonathan Taylor
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 basi
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.
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
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
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
On 3 Sep 2013, at 13:39, Jonathan Taylor 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
> 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
Opps! Typeo, should read:
[myCurrentObject setValuesFromObject: myNewObject];
Dave
On 3 Sep 2013, at 11:52, Jonathan Taylor 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
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,
On 03/09/2013, at 1:23 PM, Jonathan Taylor
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'
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 s
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
ac
> 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 nee
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 tha
On 03/09/2013, at 12:52 PM, Jonathan Taylor
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
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
27 matches
Mail list logo
