Re: crash on altering NSMutableArray
Yes, this all makes sense to me. I'm not super advanced, but I do at least understand the idea of keeping reads/writes temporally distinct. Anyway, it looks like I found the problem. There was a somewhat unnecessary (or at least easily avoidable call) happening to a method that **does** tamper with that array. I worked around it and it hasn't crashed so far. Fingers crossed. I really only need this to work for about the next hour, while I run some tests and finish my paper! ;-) thanks for your trouble. J. On 2010-05-01, at 10:55 PM, Michael Ash wrote: On Sun, May 2, 2010 at 1:50 AM, James Maxwell jbmaxw...@rubato-music.com wrote: On May 1, 2010, at 21:22, James Maxwell wrote: If I drop into the debugger arbitrarily, before the crash, and check this same array, I noticed that it is nicely filled with NSCFNumbers. But, strangely, there are too many. My guess is that you've still got multiple threads accessing the mutable array simultaneously, and that's not thread-safe if one of the accesses is changing the array. Well, there's only one object that changes the array, so I don't know how this could happen. It's a common misconception that the only worry with thread safety is avoiding multiple writers. All it takes to crash is a single write, happening simultaneous with a read. A class that's not thread safe will not tolerate this, and can crash. In general, multiple readers is fine, but the moment you make any changes, you MUST not have ANY reads occurring for the duration of the write. Basically, unless you know enough about multithreading to start doing really advanced things (and when I say really advanced, I mean the sort of level which most people never even reach), you MUST lock (or otherwise protect, e.g. funneling through a single thread, GCD serial queue, etc.) ALL accesses to any shared objects. Mike ___ 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/jbmaxwell%40rubato-music.com This email sent to jbmaxw...@rubato-music.com James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ 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
crash on altering NSMutableArray
I'm having a crash when trying to remove the last item in an NSMutableArray. The app is a pretty complex system, and runs its two main processes in consecutively executed blocks. The blocks are run using dispatch_apply, on the global queue. The operation that's trying to access the NSArray is, I think, within the first block... but honestly, I can't be totally sure, as I don't know exactly why the app is crashing. I guess what I'm wondering is whether there's some fool-proof way of protecting that NSArray from being read and changed simultaneously? I tried making the array nonatomic, but that didn't solve the problem. Of note is the fact that this is directly related to processing load, so I'm assuming it has to do with some timing thing -- as the app gets more loaded down, things get sketchy. I know this isn't a great description of the problem, but hopefully someone has some thoughts to share. Thanks in advance, J. James B Maxwell Composer/Doctoral Student School for the Contemporary Arts (SCA) School for Interactive Arts + Technology (SIAT) Simon Fraser University jbmaxw...@rubato-music.com jbmax...@sfu.ca ___ 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
Re: crash on altering NSMutableArray
On May 1, 2010, at 5:04 PM, James Maxwell jbmaxw...@rubato-music.com wrote: I'm having a crash when trying to remove the last item in an NSMutableArray. The app is a pretty complex system, and runs its two main processes in consecutively executed blocks. The blocks are run using dispatch_apply, on the global queue. The operation that's trying to access the NSArray is, I think, within the first block... but honestly, I can't be totally sure, as I don't know exactly why the app is crashing. Yes you do. You have a debugger and a stack trace. I guess what I'm wondering is whether there's some fool-proof way of protecting that NSArray from being read and changed simultaneously? I tried making the array nonatomic, but that didn't solve the problem. Of note is the fact that this is directly related to processing load, so I'm assuming it has to do with some timing thing -- as the app gets more loaded down, things get sketchy. The concept you're looking for is thread safety. It is, in general, a Very Hard Problem. I know this isn't a great description of the problem, but hopefully someone has some thoughts to share. If you have a crash, the only two useful pieces of information are the source code and the stack trace. Anything else risks misinterpretation and therefore wasted time. --Kyle Sluder ___ 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
Re: crash on altering NSMutableArray
Okay, so let me give a little more info.
Here's the stack trace.
#0 0x7fff8578693c in __CFTypeCollectionRelease
#1 0x7fff85783e43 in __CFArrayReleaseValues
#2 0x7fff85764bc8 in _CFArrayReplaceValues
#3 0x1000183ad in -[HSMM_Node addCoincidenceToBeliefMemory:] at
HSMM_Node.m:229
#4 0x100017803 in -[HSMM_Node topDown:] at HSMM_Node.m:121
#5 0x100012a94 in __-[HSMM_NetworkController
runNetworkOnInput:]_block_invoke_555 at HSMM_NetworkController.m:225
#6 0x7fff804f3e68 in _dispatch_apply2
#7 0x7fff804eb487 in dispatch_apply_f
#8 0x10001232e in -[HSMM_NetworkController runNetworkOnInput:] at
HSMM_NetworkController.m:218
#9 0x15050 in __-[OSC_Controller receivedOSCMessage:]_block_invoke_876
at OSC_Controller.m:252
#10 0x7fff804a1e63 in dispatch_sync_f
#11 0x14155 in -[OSC_Controller receivedOSCMessage:] at
OSC_Controller.m:251
#12 0x10008a2bc in -[OSCManager receivedOSCMessage:] at OSCManager.m:232
#13 0x10008af82 in -[OSCInPort handleScratchArray:] at OSCInPort.m:262
#14 0x10008bc5f in -[OSCInPort OSCThreadProc] at OSCInPort.m:240
#15 0x100054797 in -[VVThreadLoop threadCallback] at VVThreadLoop.m:76
#16 0x7fff81943e99 in __NSThread__main__
#17 0x7fff804a5f8e in _pthread_start
#18 0x7fff804a5e41 in thread_start
And the source for the method does does all the work is below. This wraps
everything up in a couple of blocks.
The second loop is the one that's causing the crash and the only way I think
this could happen would be if the
first loop hadn't completed. My, possibly totally misinformed, opinion was that
this method would run the
first loop to completion, then run the second. That is, all aNode objects
would do their thing in the first loop
**before** the second loop could start. But maybe I'm wrong about that. I have
to admit that my grasp
of GCD is pretty sketchy. If this isn't the case, and the second loop could, in
fact, start running before all
the aNode objects in the first loop had finished their processing, then I can
totally understand why it would
crash. Is there some way to ensure that? How would I make sure that
*everything* started in the first
loop finished before moving on to the second. If I do that, then my crash
should be solved.
- (void)runNetworkOnInput:(float *)inputPattern
{
printf(\n\n* Start Run \n\n);
int i, numLevels;
numLevels = [[[self network] hierarchy] count];
dispatch_queue_t hsmm_queue;
hsmm_queue = dispatch_get_global_queue(0, 0);
[self setPlaybackPossible:YES];
for(i=0;i numLevels;i++)
// run up the network
{
NSMutableArray* level = [[[self network] hierarchy]
objectAtIndex:i];
dispatch_apply([level count],
hsmm_queue,
^(size_t index) {
HSMM_Node* aNode = [level
objectAtIndex:index];
[aNode setIsPassive:NO];
if([aNode nodeLevel] == 1)
{
[aNode
setPredictionRequestsLocked:NO];
[aNode
setInputCounter:([aNode inputCounter] + 1)];
[aNode run:nil];
} else {
BOOL readyToLearn =
YES;
for(HSMM_Node* child
in [aNode childNodes])
{
if([child
nodeLevel] == 1 [[child sequencer] predictionAccuracy] 0.3)
{
readyToLearn = NO;
break;
}
}
if(readyToLearn ==
YES [aNode predictionRequestsLocked] == YES) // the child is asking for
help! the parent needs to learn
{
[aNode
setPredictionRequestsLocked:NO];
[aNode
setInputCounter:([aNode inputCounter] + 1)];
Re: crash on altering NSMutableArray
just to call off the dogs, in case there are any, I solved the crash by
re-working the logic a little.
It's cleaner the new way anyway, though I don't know whether the concurrency
stuff is really fixed
(or whether it was really broken!)
It works, and I'm a tight deadline, so that's all that matters!
J.
On 2010-05-01, at 5:54 PM, James Maxwell wrote:
Okay, so let me give a little more info.
Here's the stack trace.
#00x7fff8578693c in __CFTypeCollectionRelease
#10x7fff85783e43 in __CFArrayReleaseValues
#20x7fff85764bc8 in _CFArrayReplaceValues
#30x1000183ad in -[HSMM_Node addCoincidenceToBeliefMemory:] at
HSMM_Node.m:229
#40x100017803 in -[HSMM_Node topDown:] at HSMM_Node.m:121
#50x100012a94 in __-[HSMM_NetworkController
runNetworkOnInput:]_block_invoke_555 at HSMM_NetworkController.m:225
#60x7fff804f3e68 in _dispatch_apply2
#70x7fff804eb487 in dispatch_apply_f
#80x10001232e in -[HSMM_NetworkController runNetworkOnInput:] at
HSMM_NetworkController.m:218
#90x15050 in __-[OSC_Controller receivedOSCMessage:]_block_invoke_876
at OSC_Controller.m:252
#10 0x7fff804a1e63 in dispatch_sync_f
#11 0x14155 in -[OSC_Controller receivedOSCMessage:] at
OSC_Controller.m:251
#12 0x10008a2bc in -[OSCManager receivedOSCMessage:] at OSCManager.m:232
#13 0x10008af82 in -[OSCInPort handleScratchArray:] at OSCInPort.m:262
#14 0x10008bc5f in -[OSCInPort OSCThreadProc] at OSCInPort.m:240
#15 0x100054797 in -[VVThreadLoop threadCallback] at VVThreadLoop.m:76
#16 0x7fff81943e99 in __NSThread__main__
#17 0x7fff804a5f8e in _pthread_start
#18 0x7fff804a5e41 in thread_start
And the source for the method does does all the work is below. This wraps
everything up in a couple of blocks.
The second loop is the one that's causing the crash and the only way I think
this could happen would be if the
first loop hadn't completed. My, possibly totally misinformed, opinion was
that this method would run the
first loop to completion, then run the second. That is, all aNode objects
would do their thing in the first loop
**before** the second loop could start. But maybe I'm wrong about that. I
have to admit that my grasp
of GCD is pretty sketchy. If this isn't the case, and the second loop could,
in fact, start running before all
the aNode objects in the first loop had finished their processing, then I can
totally understand why it would
crash. Is there some way to ensure that? How would I make sure that
*everything* started in the first
loop finished before moving on to the second. If I do that, then my crash
should be solved.
- (void) runNetworkOnInput:(float *)inputPattern
{
printf(\n\n* Start Run \n\n);
int i, numLevels;
numLevels = [[[self network] hierarchy] count];
dispatch_queue_t hsmm_queue;
hsmm_queue = dispatch_get_global_queue(0, 0);
[self setPlaybackPossible:YES];
for(i=0;i numLevels;i++)
// run up the network
{
NSMutableArray* level = [[[self network] hierarchy]
objectAtIndex:i];
dispatch_apply([level count],
hsmm_queue,
^(size_t index) {
HSMM_Node* aNode = [level
objectAtIndex:index];
[aNode setIsPassive:NO];
if([aNode nodeLevel] == 1)
{
[aNode
setPredictionRequestsLocked:NO];
[aNode
setInputCounter:([aNode inputCounter] + 1)];
[aNode run:nil];
} else {
BOOL readyToLearn =
YES;
for(HSMM_Node* child
in [aNode childNodes])
{
if([child
nodeLevel] == 1 [[child sequencer] predictionAccuracy] 0.3)
{
readyToLearn = NO;
break;
}
}
if(readyToLearn ==
YES [aNode predictionRequestsLocked] == YES) // the child is asking for
help! the parent needs to learn
Re: crash on altering NSMutableArray
ugh... okay, so changing the logic cured the crashes, but also negatively
impacted the system (it's a machine-learning thing, and the old logic was
crucial to the predictive power of the system).
So, I'm back to the crash.
So, looking more closely at the NSArray itself in the debugger, the items in
the array come up as
0 NSCFNumber*
1 NSCFNumber*
2 NSObject*
3 _NSZombie_CFNumber*
4 NSObject*
I have to confess, I have no idea why they aren't all NSCFNumbers, as that's
all I'm putting in the array.
In particular, I'm curious about the _NSZombie one, as I'm assuming that's the
one that's probably causing the problems, yes?
help!
J.
On 2010-05-01, at 7:19 PM, James Maxwell wrote:
just to call off the dogs, in case there are any, I solved the crash by
re-working the logic a little.
It's cleaner the new way anyway, though I don't know whether the concurrency
stuff is really fixed
(or whether it was really broken!)
It works, and I'm a tight deadline, so that's all that matters!
J.
On 2010-05-01, at 5:54 PM, James Maxwell wrote:
Okay, so let me give a little more info.
Here's the stack trace.
#0 0x7fff8578693c in __CFTypeCollectionRelease
#1 0x7fff85783e43 in __CFArrayReleaseValues
#2 0x7fff85764bc8 in _CFArrayReplaceValues
#3 0x1000183ad in -[HSMM_Node addCoincidenceToBeliefMemory:] at
HSMM_Node.m:229
#4 0x100017803 in -[HSMM_Node topDown:] at HSMM_Node.m:121
#5 0x100012a94 in __-[HSMM_NetworkController
runNetworkOnInput:]_block_invoke_555 at HSMM_NetworkController.m:225
#6 0x7fff804f3e68 in _dispatch_apply2
#7 0x7fff804eb487 in dispatch_apply_f
#8 0x10001232e in -[HSMM_NetworkController runNetworkOnInput:] at
HSMM_NetworkController.m:218
#9 0x15050 in __-[OSC_Controller receivedOSCMessage:]_block_invoke_876
at OSC_Controller.m:252
#10 0x7fff804a1e63 in dispatch_sync_f
#11 0x14155 in -[OSC_Controller receivedOSCMessage:] at
OSC_Controller.m:251
#12 0x10008a2bc in -[OSCManager receivedOSCMessage:] at OSCManager.m:232
#13 0x10008af82 in -[OSCInPort handleScratchArray:] at OSCInPort.m:262
#14 0x10008bc5f in -[OSCInPort OSCThreadProc] at OSCInPort.m:240
#15 0x100054797 in -[VVThreadLoop threadCallback] at VVThreadLoop.m:76
#16 0x7fff81943e99 in __NSThread__main__
#17 0x7fff804a5f8e in _pthread_start
#18 0x7fff804a5e41 in thread_start
And the source for the method does does all the work is below. This wraps
everything up in a couple of blocks.
The second loop is the one that's causing the crash and the only way I think
this could happen would be if the
first loop hadn't completed. My, possibly totally misinformed, opinion was
that this method would run the
first loop to completion, then run the second. That is, all aNode objects
would do their thing in the first loop
**before** the second loop could start. But maybe I'm wrong about that. I
have to admit that my grasp
of GCD is pretty sketchy. If this isn't the case, and the second loop could,
in fact, start running before all
the aNode objects in the first loop had finished their processing, then I
can totally understand why it would
crash. Is there some way to ensure that? How would I make sure that
*everything* started in the first
loop finished before moving on to the second. If I do that, then my crash
should be solved.
- (void) runNetworkOnInput:(float *)inputPattern
{
printf(\n\n* Start Run \n\n);
int i, numLevels;
numLevels = [[[self network] hierarchy] count];
dispatch_queue_t hsmm_queue;
hsmm_queue = dispatch_get_global_queue(0, 0);
[self setPlaybackPossible:YES];
for(i=0;i numLevels;i++)
// run up the network
{
NSMutableArray* level = [[[self network] hierarchy]
objectAtIndex:i];
dispatch_apply([level count],
hsmm_queue,
^(size_t index) {
HSMM_Node* aNode = [level
objectAtIndex:index];
[aNode setIsPassive:NO];
if([aNode nodeLevel] == 1)
{
[aNode
setPredictionRequestsLocked:NO];
[aNode
setInputCounter:([aNode inputCounter] + 1)];
[aNode run:nil];
} else {
BOOL readyToLearn =
YES;
for(HSMM_Node* child
in [aNode childNodes])
{
Re: crash on altering NSMutableArray
Poking around some more...
If I drop into the debugger arbitrarily, before the crash, and check this same
array, I noticed that it is nicely filled with NSCFNumbers. But, strangely,
there are too many. The code that fills this array, is this:
- (void)
addCoincidenceToBeliefMemory:(int)coincidence
{
if(coincidence == 0)
return;
int memDepth = [[self sequencer] memoryDepth] - 1;
NSMutableArray* beliefMem = [self beliefMemory];
NSNumber* memCoinc = [[NSNumber alloc] initWithInt:coincidence];
[beliefMem insertObject:memCoinc atIndex:0];
UInt memCount = [beliefMem count];
if(memCount memDepth)
[beliefMem removeLastObject];
[memCoinc release];
}
It's set up as a stack, so I can just grab the latest number from index 0. I
know the memDepth, is **always** 5, because this is set elsewhere, and is never
changed -- it's accessed by [[self sequencer] memoryDepth]. But I'm looking at
the array right now, and it has 7 objects in it. How is that even possible?
Getting very confused... Help appreciated.
J.
On 2010-05-01, at 8:42 PM, James Maxwell wrote:
ugh... okay, so changing the logic cured the crashes, but also negatively
impacted the system (it's a machine-learning thing, and the old logic was
crucial to the predictive power of the system).
So, I'm back to the crash.
So, looking more closely at the NSArray itself in the debugger, the items in
the array come up as
0 NSCFNumber*
1 NSCFNumber*
2 NSObject*
3 _NSZombie_CFNumber*
4 NSObject*
I have to confess, I have no idea why they aren't all NSCFNumbers, as that's
all I'm putting in the array.
In particular, I'm curious about the _NSZombie one, as I'm assuming that's
the one that's probably causing the problems, yes?
help!
J.
On 2010-05-01, at 7:19 PM, James Maxwell wrote:
just to call off the dogs, in case there are any, I solved the crash by
re-working the logic a little.
It's cleaner the new way anyway, though I don't know whether the concurrency
stuff is really fixed
(or whether it was really broken!)
It works, and I'm a tight deadline, so that's all that matters!
J.
On 2010-05-01, at 5:54 PM, James Maxwell wrote:
Okay, so let me give a little more info.
Here's the stack trace.
#0 0x7fff8578693c in __CFTypeCollectionRelease
#1 0x7fff85783e43 in __CFArrayReleaseValues
#2 0x7fff85764bc8 in _CFArrayReplaceValues
#3 0x1000183ad in -[HSMM_Node addCoincidenceToBeliefMemory:] at
HSMM_Node.m:229
#4 0x100017803 in -[HSMM_Node topDown:] at HSMM_Node.m:121
#5 0x100012a94 in __-[HSMM_NetworkController
runNetworkOnInput:]_block_invoke_555 at HSMM_NetworkController.m:225
#6 0x7fff804f3e68 in _dispatch_apply2
#7 0x7fff804eb487 in dispatch_apply_f
#8 0x10001232e in -[HSMM_NetworkController runNetworkOnInput:] at
HSMM_NetworkController.m:218
#9 0x15050 in __-[OSC_Controller receivedOSCMessage:]_block_invoke_876
at OSC_Controller.m:252
#10 0x7fff804a1e63 in dispatch_sync_f
#11 0x14155 in -[OSC_Controller receivedOSCMessage:] at
OSC_Controller.m:251
#12 0x10008a2bc in -[OSCManager receivedOSCMessage:] at OSCManager.m:232
#13 0x10008af82 in -[OSCInPort handleScratchArray:] at OSCInPort.m:262
#14 0x10008bc5f in -[OSCInPort OSCThreadProc] at OSCInPort.m:240
#15 0x100054797 in -[VVThreadLoop threadCallback] at VVThreadLoop.m:76
#16 0x7fff81943e99 in __NSThread__main__
#17 0x7fff804a5f8e in _pthread_start
#18 0x7fff804a5e41 in thread_start
And the source for the method does does all the work is below. This wraps
everything up in a couple of blocks.
The second loop is the one that's causing the crash and the only way I
think this could happen would be if the
first loop hadn't completed. My, possibly totally misinformed, opinion was
that this method would run the
first loop to completion, then run the second. That is, all aNode
objects would do their thing in the first loop
**before** the second loop could start. But maybe I'm wrong about that. I
have to admit that my grasp
of GCD is pretty sketchy. If this isn't the case, and the second loop
could, in fact, start running before all
the aNode objects in the first loop had finished their processing, then I
can totally understand why it would
crash. Is there some way to ensure that? How would I make sure that
*everything* started in the first
loop finished before moving on to the second. If I do that, then my crash
should be solved.
- (void)runNetworkOnInput:(float *)inputPattern
{
printf(\n\n* Start Run \n\n);
int i, numLevels;
numLevels = [[[self network] hierarchy] count];
dispatch_queue_t hsmm_queue;
hsmm_queue = dispatch_get_global_queue(0, 0);
[self setPlaybackPossible:YES];
for(i=0;i numLevels;i++)
// run up
Re: crash on altering NSMutableArray
On May 1, 2010, at 20:42, James Maxwell wrote: So, looking more closely at the NSArray itself in the debugger, the items in the array come up as 0 NSCFNumber* 1 NSCFNumber* 2 NSObject* 3 _NSZombie_CFNumber* 4 NSObject* This strongly suggests a memory management problem -- something is over-releasing the items in the array. On May 1, 2010, at 21:22, James Maxwell wrote: If I drop into the debugger arbitrarily, before the crash, and check this same array, I noticed that it is nicely filled with NSCFNumbers. But, strangely, there are too many. My guess is that you've still got multiple threads accessing the mutable array simultaneously, and that's not thread-safe if one of the accesses is changing the array. You're fighting this battle on too many fronts. You've got a sketchy grasp of GCD, you're uncertain whether you're actually multithreading or not, and this sort of let-everything-poke-every-object-from-every-direction application design really makes it to determine correctness. Probably you should pick one thing, and comment everything else out, until you're sure that small part is working. Then add the complexity back in slowly, checking correctness at each step. FWIW. ___ 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
Re: crash on altering NSMutableArray
This strongly suggests a memory management problem -- something is
over-releasing the items in the array.
okay, this is what I figured, but I can't see anywhere where this could be
happening.
On May 1, 2010, at 21:22, James Maxwell wrote:
If I drop into the debugger arbitrarily, before the crash, and check this
same array, I noticed that it is nicely filled with NSCFNumbers. But,
strangely, there are too many.
My guess is that you've still got multiple threads accessing the mutable
array simultaneously, and that's not thread-safe if one of the accesses is
changing the array.
Well, there's only one object that changes the array, so I don't know how
this could happen.
I would like to know, though, whether this:
for(i=numLevels - 1;i = 0;--i) // run
back down the network
{
NSMutableArray* level = [[[self network] hierarchy]
objectAtIndex:i];
dispatch_apply([level count],
hsmm_queue,
^(size_t index) {
HSMM_Node* aNode;
aNode = [level
objectAtIndex:index];
[aNode
getEvidenceFromParents];
[aNode topDown:[aNode
parentEvidence]];
if([aNode nodeLevel] == 1)
[[aNode sequencer]
predictForward:NO];
});
}
will process all of the aNode objects on the current level, before moving
on to the next level?
My intention with the above code is to process each level in parallel, but to
finish processing a level before moving to the next level. If this is not the
proper way to do that, I'd really appreciate any help in correcting this code.
thanks,
J.
___
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
Re: crash on altering NSMutableArray
On Sun, May 2, 2010 at 1:50 AM, James Maxwell jbmaxw...@rubato-music.com wrote: On May 1, 2010, at 21:22, James Maxwell wrote: If I drop into the debugger arbitrarily, before the crash, and check this same array, I noticed that it is nicely filled with NSCFNumbers. But, strangely, there are too many. My guess is that you've still got multiple threads accessing the mutable array simultaneously, and that's not thread-safe if one of the accesses is changing the array. Well, there's only one object that changes the array, so I don't know how this could happen. It's a common misconception that the only worry with thread safety is avoiding multiple writers. All it takes to crash is a single write, happening simultaneous with a read. A class that's not thread safe will not tolerate this, and can crash. In general, multiple readers is fine, but the moment you make any changes, you MUST not have ANY reads occurring for the duration of the write. Basically, unless you know enough about multithreading to start doing really advanced things (and when I say really advanced, I mean the sort of level which most people never even reach), you MUST lock (or otherwise protect, e.g. funneling through a single thread, GCD serial queue, etc.) ALL accesses to any shared objects. Mike ___ 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
