Re: Semaphore strangeness
Re: Semaphore strangeness
- Subject: Re: Semaphore strangeness
- From: Charles Srstka <email@hidden>
- Date: Wed, 17 Apr 2013 19:44:57 -0500
On Apr 17, 2013, at 7:06 PM, Greg Parker <email@hidden> wrote:
> On Apr 17, 2013, at 4:14 PM, Quincey Morris <email@hidden> wrote:
>
>> I'm not sure if this is the right list for this, but then I'm not sure what is the right list.
>>
>> I'm seeing a consistent problem disposing of GCD semaphores. For example, if I create a semaphore like this:
>>
>> semaphore = dispatch_semaphore_create (10);
>>
>> and then use if for a while, then try to destroy it (using ARC):
>>
>> semaphore = nil;
>>
>> If the semaphore's count is less than the original value (10 in the example), I get a EXC_BAD_INSTRUCTION crash.
>>
>> It's not clear to me why it should matter whether the original count has been restored. There's nothing waiting on the semaphore -- the operations that decremented the count have themselves be disposed of already.
>>
>> If I forcibly increment the count to 10 *or more*, there's no crash.
>
> dispatch assumes you are using the semaphore in a lock-like pattern, where all waiters are expected to signal when they are done with their work. In that pattern, destroying a semaphore whose value is less than its original value indicates a bug somewhere (because somebody should have signaled the semaphore but has not yet done so). _dispatch_semaphore_dispose() is enforcing that assumption and deliberately halting your process if it fails.
Then why not use something like an assertion or an exception which could actually let the user / developer know why you crashed, instead of just EXC_BAD_INSTRUCTION?
Charles
_______________________________________________
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