• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag
 

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Locking from within an enumerator
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Locking from within an enumerator


  • Subject: Re: Locking from within an enumerator
  • From: James Chen <email@hidden>
  • Date: Wed, 21 Apr 2004 10:11:18 +0800

Hi,
Base on your original logic; when caller query the enumerator, you lock the data model. And unlock it after the enumerator dealloc.
Your approach is making the critical section as long as the enumerator's life.
How about this. When caller query the enumerator, you return the enumerator after locking the data model successfully. And force the caller to call other method to unlock the data model.
This has a short coming which makes the object a little unfriendly.

-----------------------------------------------------------Data Model
- (NSEnumerator*)lockModelAndGetEnumerator
{
if (m_InternalLock tryLock) { // lock or tryLock based on your strategy
return [dataArray objectEnumerator];
} else
return nil;
}
- (void)unlock
{
[m_InternalLock unlock];
}

-----------------------------------------------------------Thread

- (void)doSomething
{
NSEnumerator *enumerator = [dataModel lockModelAndGetEnumerator];
if (enumerator) {
id obj;
while (obj = [enumerator nextObject]) {
[obj doSomethingElse];
}
[dataModel unlock];
}
}

HTH,
James

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?

Mike
_______________________________________________
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.
_______________________________________________
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.


  • Follow-Ups:
    • Re: Locking from within an enumerator
      • From: "Mike R. Manzano" <email@hidden>
References: 
 >Locking from within an enumerator (From: "Mike R. Manzano" <email@hidden>)

  • Prev by Date: Re: Enabling NSMenuItem in Code?
  • Next by Date: Re: Linking problem
  • Previous by thread: Re: Locking from within an enumerator
  • Next by thread: Re: Locking from within an enumerator
  • Index(es):
    • Date
    • Thread