Thanks, Mike.
I assume that I need to also use
#define OPERATION_NOT_FINISHED 0
and
condLock = [[NSConditionLock alloc] initWithCondition: OPERATION_NOT_FINISHED];
Right?
I have a doubt here, however. What if the cancel message is sent even
before the worker thread had the possibility to start? In that case,
the NSOperation may remove itself from the queue and never start its
worker thread altogether. Than the main thread will deadlock because
the condition will never be OPERATION_FINISHED. How to fix this?
> Yeah, don't do this. Locks are for mutual exclusion *only*.
> Use NSConditionLock, something like this:
> #define OPERATION_FINISHED 1
> // operation exit
> [condLock lock];
> [condLock unlockWithCondition:OPERATION_FINISHED];
> // wait for exit
> [condLock lockWhenCondition:OPERATION_FINISHED];
> [condLock unlock];
> Mike
On Thu, Feb 12, 2009 at 3:09 PM, Oleg Krupnov <oleg.krup...@gmail.com> wrote:
> Can someone please give me a sample of the valid way of using
> NSCondition for this? I am still confused regarding how I can avoid
> the subtle sync errors.
>
> I've tried the following code
>
> // main thread
> // cancel operation
> [m_operation cancel];
> // wait until operation exits
> [m_operationCompletionCondition lock];
> [m_operationCompletionCondition wait];
> [m_operationCompletionCondition unlock];
>
> The operation object:
>
> - (id) initWithCompletionCondition:(NSCondition*)completionCondition
> {
> ...
> m_completionCondition = [completionCondition retain];
> // lock the condition while in the main thread
> [m_completionCondition lock];
>
> }
>
> // Worker thread's main
> - (void)main
> {
> ...
> // signal operation completed from the worker thread
> [m_completionCondition signal];
> [m_completionCondition unlock];
> }
>
> The problem is however that sometimes the worker thread exits in
> between the -cancel message and before the -wait message. So there is
> nothing to wait anymore and the program waits endlessly. I don't see
> how to resolve this problem without going too sophisticated. I must be
> doing something wrong, don't I?
>
>
> On Thu, Feb 12, 2009 at 1:39 PM, Andrew Farmer <andf...@gmail.com> wrote:
>> On 12 Feb 09, at 01:25, Oleg Krupnov wrote:
>>>
>>> This seems a trivial question for a multi-threading app, but I haven't
>>> been successful in implementing this in Cocoa. I've got deadlocks and
>>> strange logs for seemingly no reason.
>>
>> <snip>
>>>
>>> // the operation object eventually checks the -isCancelled flag and
>>> then sends -unlock to the lock, and its thread exits.
>>
>> This is not an appropriate use of locks, and the runtime error you're
>> getting ("lock unlocked from thread which did not lock it") is a sign of
>> this misuse. Indeed, the design you've described actually contains a subtle
>> synchronization error that could cause deadlock if your code attempts to
>> cancel a thread before it has fully initialized.
>>
>> As a general point, though, locks are designed for mutual exclusion on
>> shared resources, not inter-thread signalling. Use NSCondition for this sort
>> of communication; alternatively, you may want to investigate pthread_cancel
>> for a more specific solution.
>>
>
_______________________________________________
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
