Re: Accessing buffers in NSData/NSMutableData under garbage collection
Re: Accessing buffers in NSData/NSMutableData under garbage collection
- Subject: Re: Accessing buffers in NSData/NSMutableData under garbage collection
- From: Alastair Houghton <email@hidden>
- Date: Tue, 19 Feb 2008 14:46:13 +0000
On 19 Feb 2008, at 14:26, Adam P Jenkins wrote:
On Feb 19, 2008, at 1:24 AM, Chris Suter wrote:
On 19/02/2008, at 4:23 PM, Adam P Jenkins wrote:
Oops, I left out __strong, I meant the second statement to be:
__strong float *myPointer =
NSAllocateCollectable(size*sizeof(float), 0);
It doesn't make any difference.
Everything on the stack or in a register is implicitly strong.
Where did you find that information? I'm not saying it isn't true,
but I'd just like to know what else I should be reading. In the
definition of __strong in the GC Programming Guide, it has this to
say:
Well it isn't *quite* true. The point is that a thread's stack and
registers are scanned by the collector, and anything that looks like a
pointer to an object will be traced.
"__strong" has two purposes; it ensures that a write barrier is used
when accessing the variable, which is important for detection of
intergenerational pointers and also (I think) for synchronising access
between the mutator (your code) and the collector, plus it causes the
compiler to add information about the variable to the Objective-C
section of the final Mach-O binary. There is no place in the binary
for information about stack variables and registers, and since the
stack and registers aren't part of a particular object's storage, they
can't be intergenerational pointers either; they're also thread-local,
so the collector doesn't need to synchronise access because it stops
the thread in order to scan the stack.
Anyway, the long and short of it is that __strong doesn't currently do
anything for local variables.
<quote>
__strong is implicitly part of any declaration of an Objective-C
object reference type. You must use it explicitly if you need to use
Core Foundation types, void *, or other non-object references
</quote>
which led me to believe I needed to use __strong any time I want a
non-object pointer to be noticed by the GC.
It's safe to use __strong everywhere, but it won't actually do
anything (and as a result isn't really necessary) for variables held
on the stack (i.e. local variables).
Also, regarding the NSString UTF8String problem you mentioned: It
seems to me that the problem would be just as possible if you used
an NSMutableData object to allocate the memory, even if you made
sure to store a reference to the object in a variable. That is, doing
NSMutableData *data = [NSMutableData
dataWithLength:count*sizeof(float)];
float *ptr = [data mutableBytes];
// do stuff with ptr, never refer to data variable
could also land you in trouble. It seems to me that the compiler
might optimize away the data variable in the above code
Assuming you never refer to the data variable again, yes, it could. A
solution would be to stick "volatile" on the "data" variable, e.g.
NSMutableData * volatile data = [NSMutableData dataWithLength:count
* sizeof(float)];
to prevent the compiler from optimizing it away.
if it was never accessed again after the line which calls
mutableBytes, so you could run into the same problem, where the
NSMutableData object gets GCed before you're done using ptr, unless
you declared data to be volatile. So the problem isn't with
NSAllocateCollectable only.
Indeed.
Kind regards,
Alastair.
--
http://alastairs-place.net
_______________________________________________
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