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
