On Oct 7, 2016, at 15:37 , Dave Fernandes <dave.fernan...@utoronto.ca> wrote: > > But I don’t see how incrementing it after creating it is any different from > creating it with a non-zero count. Either way, if you have resources > available, the count will be non-zero, and you will crash if you try to > deallocate.
The difference is internal: the semaphore remembers what its initial count was, and the semaphore requires the count to be at least as large at the time of deallocation. It’s supposedly a sanity check. There’s no *functional* reason for it. The rationale is that a lower count indicates that you’ve “leaked” resources: if the resources had all been “released” back into the pool the count would have returned to its initial value. The situation I encountered was with Audio Queue Services, where I was using a semaphore to control access to a pool of buffers. Under some error conditions, I abandoned playback and disposed of the audio queue, but the queue then did not call the delegate method that normally informs the client of available buffers (though the buffers weren’t actually leaked, just silently disposed of). The app then crashed when disposing of the semaphore. Note that there’s no check of the opposite condition: if the count at disposal is greater than the initial count, there’s no crash. One workaround would be to force-increment the semaphore before disposing of it, if necessary, but it’s slightly easier to create the semaphore with a zero count and pre-increment it to the starting resource count. _______________________________________________ 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
