This isn't 'real code'. This is merely an attempt to learn GCD & concurrency: sharing common data, etc.
The reason for alloc a NSNumber is to work with the heap vs stack. I'll also be working with C structures as well. Yes, working with static int mynum is of course, much simpler. I'll peek at OSAtomic.h I'm in a learning phase, so I'll expect to 'flutter about' before I can fly. 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]; Ric. Concurrent Neophyte. On Nov 15, 2010, at 12:36 PM, Scott Ribe wrote: > > On Nov 15, 2010, at 1:06 PM, Frederick C.Lee wrote: > >> 1) How do I properly release my static NSNumber *myNumber after use? > > Why would you want to? The point of a static is to last the lifetime of the > application. > > However, your code as you posted it, is quite messed up. You create a number > that you own and store the pointer in myNumber. Then you repeatedly reassign > myNumber with a new object which you do not own and which will be dealloc'd > out from under you at some point in the future. > >> 2) Is the @synchronized() directive required within myPrintResults() to >> protect from possible thread crashes? > > Well, if you insist on allocating new NSNumbers and reassigning them all them > time, absolutely. Even if you fix the memory management, you still have to > guard against simultaneous execution of the method body because, well, all > sorts of things could go wrong with that code. > > Is this real code? Are you really just accumulating a counter? > > If so, I would suggest starting with a major simplification: > > static int mynum = 0; > mynum += 5; > > Even then, you still have to guard against overlapping execution. Although at > least the worst case is an increment operation being "lost", instead of > crashing. You can avoid that problem easily with @synchronized, or you can > take a peek at OSAtomic.h... > > > -- > Scott Ribe > scott_r...@elevated-dev.com > http://www.elevated-dev.com/ > (303) 722-0567 voice > > > > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
