dispatch_once_t must have global or static scope?
The GCD reference on developer.apple.com says, regarding dispatch_once_t: "Variables of this type must have global or static scope. The result of using this type with automatic or dynamic allocation is undefined." https://developer.apple.com/library/mac/#documentation/Performance/Reference... However, I can't find any explanation of why that would be the case, either in the documentation or the libdispatch code. Does anyone have any insight to shed on this? It's occasionally useful to have a dispatch_once_t member variable in an Objective-C object, and it would be nice to know if that's actually OK or not. I have a hard time figuring out how GCD could possibly care about the storage scope of the variable, but it's possible that I'm overlooking something. Mike
Hi Mike, 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. Daniel On Jul 26, 2012, at 10:14, Michael Ash <michael.ash@gmail.com> wrote:
The GCD reference on developer.apple.com says, regarding dispatch_once_t:
"Variables of this type must have global or static scope. The result of using this type with automatic or dynamic allocation is undefined."
https://developer.apple.com/library/mac/#documentation/Performance/Reference...
However, I can't find any explanation of why that would be the case, either in the documentation or the libdispatch code. Does anyone have any insight to shed on this? It's occasionally useful to have a dispatch_once_t member variable in an Objective-C object, and it would be nice to know if that's actually OK or not. I have a hard time figuring out how GCD could possibly care about the storage scope of the variable, but it's possible that I'm overlooking something.
Mike _______________________________________________ libdispatch-dev mailing list libdispatch-dev@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo/libdispatch-dev
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)? 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.... In any case, thanks a lot for your quick reply. Mike
On Jul 26, 2012, at 10:39, Michael Ash <michael.ash@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
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 Daniel
On Jul 26, 2012, at 1:57 PM, Daniel A. Steffen wrote:
On Jul 26, 2012, at 10:39, Michael Ash <michael.ash@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
participants (2)
-
Daniel A. Steffen
-
Michael Ash