Re: Semaphore strangeness
Re: Semaphore strangeness
- Subject: Re: Semaphore strangeness
- From: Quincey Morris <email@hidden>
- Date: Wed, 17 Apr 2013 18:36:40 -0700
On Apr 17, 2013, at 17:06 , Greg Parker <email@hidden> wrote:
> 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.
One example where the assumption doesn't hold is where the semaphore is controlling access to AudioQueueBuffers for an AudioQueue. Calling AudioQueueDispose suppresses further calls of the buffer release callback, where the semaphore is signaled. After that, you don't get any outstanding buffers back again, and your semaphore count is borked.
(If you try to use AudioQueueStop first, you then have to orchestrate a *wait* for all outstanding buffers to arrive at the callback, for no other purpose than satisfying the count requirement, before destroying the related semaphore. This adds *harder* synchronization code to solve a problem that never really existed.)
My assumption would be that, if you're destroying the semaphore, you're shutting some procedure down, so you likely have taken care of the waiters already. If you haven't, that's clearly a bug and they're going crash anyway when they try to signal a nil ivar or an invalid semaphore. There's no point in crashing at semaphore-disposal time.
Anyway, my workaround is now to signal the semaphore 'originalCount' times before disposing of it.
On Apr 17, 2013, at 17:55 , Greg Parker <email@hidden> wrote:
> There should be a message in the crash log.
>
> if (dsema->dsema_value < dsema->dsema_orig) {
> DISPATCH_CLIENT_CRASH("Semaphore/group object deallocated while in use");
> }
I couldn't find one. Maybe the "bad instruction" crash was a failed attempt to log this message?
_______________________________________________
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