On Nov 12, 2012, at 8:36 AM, Ken Thomases <k...@codeweavers.com> wrote: > Far be it from me to discourage people from paying attention to the docs, but > I'm pretty sure that the docs are excessively restrictive in this case. > > From working with similar constructs in other APIs, I believe the actual > requirements are: > > 1) All of the threads which are to coordinate on doing a task exactly once > must be referring to the same storage for the once predicate. > > 2) The predicate storage has to be guaranteed to have been allocated and > initialized to zero before any threads access it. > > 3) The storage must not be deallocated until after it is guaranteed that no > threads will reference it again. > > Obviously, automatic storage violates rule 1. Most schemes which try to > dynamically allocate the storage just before it's needed would normally run > into the same race condition that dispatch_once() is trying to solve. And > the most common anticipated use case is for ensuring that a given task is > only performed once, globally. So, avoiding dynamic storage is a nice simple > rule. (It's also easy to forget to set dynamically allocated storage to zero > before using it.) > > But an instance variable still satisfies all three requirements for the case > where a task needs to be performed only once per instance. > > And the blog's speculation that there's some special characteristic of > statically allocated memory vs. dynamically allocated memory that is > important to dispatch_once()'s synchronization strikes me as very, very > improbable.
There is something special about statically-allocated memory. Statically-allocated memory has always been zero for the life of the process. Dynamically-allocated memory may have been non-zero at some point in the past (i.e. if it was previously part of a now-freed allocation). The problem is your condition #2. If the memory was previously non-zero and you set it to zero, you need appropriate memory barriers on some architectures to prevent a race where the caller of dispatch_once() sees the old non-zero value. Neither dispatch_once() nor the malloc system nor the Objective-C runtime promise to provide the correct barriers. In some cases you might be able to add an appropriate memory barrier to your -init... method, assuming that no calls to dispatch_once() occur before then. In practice this is a difficult race to hit, but it's not impossible. -- Greg Parker gpar...@apple.com Runtime Wrangler _______________________________________________ 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
