Re: NSImage drawInRect deadlock
Re: NSImage drawInRect deadlock
- Subject: Re: NSImage drawInRect deadlock
- From: Quincey Morris <email@hidden>
- Date: Tue, 09 Aug 2016 23:48:21 -0700
- Feedback-id: 167118m:167118agrif8a:167118sOKy5BARzv:SMTPCORP
On Aug 9, 2016, at 20:47 , Andrew Keller <email@hidden> wrote:
>
> 2. When utilizing Mike’s approach to limiting the number of parallel tasks down to, say, 1-8, I have been completely unable to reproduce the deadlock.
> 3. When utilizing Mike’s approach to limiting the number of parallel tasks, Xcode is still saying that threads a being created like crazy — almost one thread per block submitted to the queue.
I’m not a big fan of Mike’s proposed solution. If you want to use N-wide parallelism, then use NSOperationQueue, not GCD.
Blocks dispatched to GCD queues should not contain any internal waits, such as for I/O. Instead, a dispatched block should occupy the CPU continuously, and at the end do one of 3 things:
1. Just exit.
2. Start an asynchronous action, such as GCD I/O, with a completion handler that’s not scheduled until the action is done.
3. Queue another block that represents another processing step in the overall task being performed.
The point of #3 is that I think it’s also a mistake to queue large numbers of blocks to GCD all at once, for the pragmatic reason that if you accidentally violate the non-internal-waits rule, the size of the thread explosion depends on the amount of combustible material that’s queued. It’s better for *each operation* to queue its successor, and to start the whole thing off by priming the pump with a modest number of blocks.
The other thing to be very careful of is global locks. If your code (perhaps outside your direct control) hits any global locks that affect multiple threads, *and* if the kind of lock being used is slower to test when locked than when unlocked, then more parallelism can be counterproductive.
I’ve run into this in cases where adding more operations on more CPUs just adds a disproportionate amount of system overhead, decreasing the throughput of the actual calculation.
The point of all this is that you may not have enough control of the internal behavior of those NSImage methods to safely use GCD parallelism for a job like this. NSOperationQueue might be a better solution.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden