Re: Locking from within an enumerator
Re: Locking from within an enumerator
- Subject: Re: Locking from within an enumerator
- From: Dustin Voss <email@hidden>
- Date: Wed, 21 Apr 2004 11:37:44 -0700
On 20 Apr, 2004, at 4:30 PM, Mike R. Manzano wrote:
I have a data model that can be accessed by multiple threads at once.
It is basically an array of stuff. I want to be able to allow threads
to iterate over the data model, and so I was thinking of creating an
NSEnumerator subclass that locks the model for the duration of the
enumerator's life. The problem with this is that I don't know when the
NSEnumerator will have its dealloc called (actually, I don't even know
if dealloc is really ever called - I put NSLogs in - (void) dealloc
before, but the NSLogs never print out).
Anyway, back to the main point, assuming dealloc is eventually called,
I'm not sure if I can depend on that behavior to call unlock for me.
Does anyone have a better obj-c design pattern for iterating over an
array in a multithreaded environment?
Why bother to lock it? You might lock the collection to keep another
thread from modifying it, but "it isn't safe to modify a mutable
collection while enumerating through it" so you can't modify it anyway
and locking is unnecessary.
You might want to lock individual elements of the collection, but you
can just use @synchronized for that, and the enumerator doesn't have to
worry about it -- the elements' ids won't be changing.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.