On 2.12.2009, at 18:27, Jim Thomason wrote: >> It shouldn't deadlock. The doc for -lock says: "If you lock (or successfully >> tryLock) a managed object context, the thread in which the lock call is made >> must have a retain until it invokes unlock. If you do not properly retain a >> context in a multi-threaded environment, this will result in deadlock." Did >> you heed it? > > It didn't matter one way or the other. Incidentally, I've seen that > warning too, but in this case I was sharing the [document > managedObjectContext] across threads, so it was guaranteed to exist as > long as the window was open. So I take it that you have code in place that postpones window closing while your background thread works with the context? > What was the need to retain it in that > case, anyway? To safe writing above code. > > Sigh. Nevermind, I'm an idiot. My worker thread that refreshes my > graph does 3 different things in it. 1 is fairly old and has been > around for months, the other 2 things are newly added. > > The original one ended up calling rearrangeObjects on an array > controller, and since that's not threadsafe (right?) I dispatched the > call to the main thread, and helpfully set waitUntilDone:YES. That was > fine originally, since the app was guaranteed not to be looking at the > context in the main thread, and basically I got lucky and could get > away with it. > > But now, due to additional processing in the main thread, it was > looking at the context. So my worker thread would happily chug along > until it reached the rearrangeObjects call. It'd hand it off to the > main thread and wait for it to finish. But the main thread was paused > since my worker thread had the lock on the context. And blamo. > Deadlock. > > Solution? Disturbingly easy to see now 12 hours into trying to fix it. > Just do the rearrangeObjects on the main thread as before, but set > waitUntilDone:NO. All problems miraculously fixed.
And an important lesson learned: blocking or waiting in any way while holding a lock is a dangerous thing to do. Kai _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
