Re: Releasing static variable & concurrent data protection questions...
Re: Releasing static variable & concurrent data protection questions...
- Subject: Re: Releasing static variable & concurrent data protection questions...
- From: "Frederick C. Lee" <email@hidden>
- Date: Mon, 15 Nov 2010 14:09:19 -0800
Ultimate scenario:
Predicting satellites... one...many.
Each satellite is govern my Keplerian physics {drag,....etc.}; so I'll be working with a dozen+ variables, in parallel/concurrently.
Programming Scenario:
a) Satellites' identifiers stored in Core Data. <--- Done.
b) User select selects a one or more satellites to track/predict.
Calculating Data Vector: C structs vs ObjC objects.
Hence, I would like to use GCD in managing concurrent processes, sharing data.
The design is nascent: exploring various paradigms using ^blocks.
What I've learnt, know:
1) Static variables shouldn't be released, good for the entire life of the application.
2) Static variables on stack <-- I was aware of this.
3) Heap data are easier (?) to share vs stack; hence considering working with pointers to head objects.
My current ignorant design:
One current design is to iterate a ^block (rep. satellite's idiosyncrasies) concurrently, with each iteration calculating accumulating data.
Hence I need to share persistent C-struct{} of data.
Something like this:
for (processData) {
dispatch_async(dispatch_get_main_queue(), ^(void) {
calcSat(dataVar); // where dataVar would be a C-struct.
});
}
Second (2nd) design:
Create one (1) ^block that exists for the ENTIRE iteration of the data. That is, iterate the calculations WITHIN the block till a specific condition
is meet OR cancelled via outside request.
I'm thinking the 2nd design is better.
In the meantime, I'm toying with ObjC/C in various scenarios to learn the beast.
Ric.
On Nov 15, 2010, at 1:48 PM, Scott Ribe wrote:
> On Nov 15, 2010, at 2:08 PM, Frederick C. Lee wrote:
>
>> This isn't 'real code'.
>> This is merely an attempt to learn GCD & concurrency: sharing common data, etc.
>
> OK.
>
>> The reason for alloc a NSNumber is to work with the heap vs stack.
>> I'll also be working with C structures as well.
>
> static int wouldn't be on the stack either, FYI. What exactly is the concern with heap vs stack? Just experimentation & learning? Or are you looking for heap allocation for a specific reason?
>
>> I'm in a learning phase, so I'll expect to 'flutter about' before I can fly.
>
> If you're learning threads, expect to crash & burn a few times ;-)
>
>> BTW: working with static variables - Is it possible to using 'static' within a 'task'; i.e., releasing it BEFORE the end of the application termination?
>>
>> Something like this:
>>
>> NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init];
>> ...
>> static NSNumber *myNum = [[NSNumber alloc] initwithInt:0] autorelease]?
>> ...
>> [pool drain];
>
> That code would compile and run, and after the [pool drain] statement you'd have a pointer, myNum, to a deallocated NSNumber, which you couldn't (or, shouldn't) use for anything. Remember, in that code the *pointer* is static, not the object to which it points.
>
> Why do you care about deallocating statics? It's not something that's generally useful. Granted, there might be some situation where you want to replace a static pointer-to-object with a different pointer, so you'd need to release before assigning in order to avoid a leak...
>
> --
> Scott Ribe
> email@hidden
> http://www.elevated-dev.com/
> (303) 722-0567 voice
>
>
>
>
_______________________________________________
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