> On 23 Jul 2016, at 12:45 AM, Trygve Inda <cocoa...@xericdesign.com> wrote:
>
> Because the main thread sometimes needs to ask the worker threads to
> terminate. If it does this after performOnMainThread has been called by a
> worker thread, but before the main thread has processed it, then the main
> thread will block waiting for the worker thread to exit, but the worker
> thread has already blocked when it called performOnMainThread.
>
> Very rare, but it can happen.
This is wrong thinking.
If the worker thread is waiting for -performOnMainThread to complete, it
*cannot* possibly get a call from the main thread to terminate, because the
main thread is dealing with whatever the other thread asked it to do.
If the worker thread performs a copy and doesn’t wait for the main thread to
perform the drawing, then it’s still “blocked” while it’s performing the copy.
Either your understanding of the bug is wrong, or there’s somethomg whiffy in
your architecture.
Usually a worker thread just checks a flag on each loop and falls out when it
gets set (by another thread). That flag should be set atomically. There can
then be no deadlock.
e.g.
worker thread:
while( self.running )
{
// do work
window.imageRep = myResult;
// window.imageRep is (atomic, copy)
[performOnMainThread: window.setNeedsDisplay]; // this is
obviously pseudocode!
}
main thread, when it needs to terminate worker thread:
workerThread.running = NO;
both workerThread.running and window.imageRep are atomic properties.
—Graham
_______________________________________________
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
