[libdispatch-dev] dispatch_once_t must have global or static scope?

[Michael Ash]

On Jul 26, 2012, at 1:57 PM, Daniel A. Steffen wrote:

> On Jul 26, 2012, at 10:39, Michael Ash <michael.ash at gmail.com> wrote:
> 
>> On Jul 26, 2012, at 1:30 PM, Daniel A. Steffen wrote:
>> 
>>> the main issue with dynamically allocated storage is safe initialization of the dispatch_once token value.
>>> E.g. for an object with a dispatch_once_t instance variable, depending on how that object is made visible to other threads after creation, a memory barrier will be required on some platforms to ensure the zeroing of the dynamically allocated storage is visible to other CPUs before the object pointer.
>> 
>> Excellent! That's exactly the sort of thing I was hoping I hadn't thought of before, in terms of understanding the limitation.
>> 
>> Do I understand it correctly, then, that it's safe as an Objective-C instance variable, as long as you take the standard necessary measures before letting a pointer to that ivar leak out to other threads (memory barriers or synchronization to ensure that other threads see fully initialized object contents)?
> 
> the only other potential issue could be alignment (since the token is operated on with atomic instructions), I don't know if ObjC actually makes any guarantees about ivar storage layout

I think the guarantee is there but kind of implicit, coming from C's rules on dynamic allocation and struct member allocation. In any case, I'm certain that it would break a ton of code to misalign the stuff now, so it can probably be counted on as a de facto guarantee at this point.

>> Would it be possible to have a brief discussion of this added to the documentation? This may be a bit beyond the level that the docs intend to cover, though....
> 
> indeed that is probably why the documentation on the developer site doesn't go into it, but please file a bugreport about it anyway

I'll do that. Thanks a lot for the info.

Mike
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/libdispatch-dev/attachments/20120726/c5ffbbd6/attachment.html>