Re: How to implement readonly property
Re: How to implement readonly property
- Subject: Re: How to implement readonly property
- From: Greg Parker <email@hidden>
- Date: Mon, 12 Nov 2012 12:45:29 -0800
On Nov 12, 2012, at 8:36 AM, Ken Thomases <email@hidden> 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 email@hidden Runtime Wrangler
_______________________________________________
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