• 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: Yet another threading question...
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Yet another threading question...


  • Subject: Re: Yet another threading question...
  • From: Stamenkovic Florijan <email@hidden>
  • Date: Fri, 27 Feb 2009 14:37:35 -0400

On Feb 27, 2009, at 14:08, Chuck Hill wrote:

On Feb 27, 2009, at 5:23 AM, Stamenkovic Florijan wrote:

In that scenario: nothing.

But, if I have threads X and Y altering the state of an EC (which I do at the moment, with disastrous results), and instead getting threads X and Y to get thread Z to alter the state of the EC would accomplish that the EC is only ever touched by thread Z. In short, I could have 50 threads doing work in a single EC, but the EC only ever getting touched by one. Which I hope would solve the deadlock / exception problem I have at the moment. Plus, since only thread would be actually doing the work, it would have the side effect of task queuing and synchronization on the EC. See my point?

No, not really. But I did just put another pot of coffee on. It still seems to me like you are just moving the problem / potential problem from one place to another.

Possibly. I am not sure what this will do to EOF. It's an idea, I'm working on the implementation, but only tests will show. However, I believe it has merit. Please bear with me for a bit longer.


Attached are two sources, a proof of concept. One is JBND's WorkerThread with some new additions that I put in to make this work. Not extensively tested yet, but it *seems* to function OK. Anyway, you need the WorkerThread in order to run the test. The second source is the Test source. It contains the test code, and two classes: SomeClass and SomeClassOneThreadedAccess (a subclass of SomeClass). In-source documentation explains the concept. Check out line 13 to see how to run the tests. Lines 38 and 62 explain the concept. The idea is to make an EOEditingContext subclass that does what SomeClassOneThreadedAccess does to SomeClass.

Hope this helps illustrate what I am thinking of. It's a bit weird. But so far it has been successful, outside of doing it inside EOF of course.

F

p.s. - it adds some overhead. A constant amount of overhead per method invocation. It is significant. However, hopefully far from damaging.

Attachment: Archive.zip
Description: Zip archive


 _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:

This email sent to email@hidden

  • Follow-Ups:
    • [DITCHED] Re: Yet another threading question...
      • From: Stamenkovic Florijan <email@hidden>
References: 
 >Yet another threading question... (From: Stamenkovic Florijan <email@hidden>)
 >Re: Yet another threading question... (From: Chuck Hill <email@hidden>)
 >Re: Yet another threading question... (From: Stamenkovic Florijan <email@hidden>)
 >Re: Yet another threading question... (From: Chuck Hill <email@hidden>)

  • Prev by Date: Re: oops, EditingContext disposed?
  • Next by Date: Re: [WORKED AROUND] Re: Bug in client side EOF locking?
  • Previous by thread: Re: Yet another threading question...
  • Next by thread: [DITCHED] Re: Yet another threading question...
  • Index(es):
    • Date
    • Thread