• 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 problem
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Locking problem


  • Subject: Re: Locking problem
  • From: Peter Vandoros <email@hidden>
  • Date: Thu, 16 Oct 2008 10:10:25 +1100

Try commenting out the use of the java.util.concurrent.locks.Lock code in you EC subclass and see if that helps. I suspect that somewhere under the hood your EC is being locked by directly using the private NSLock instance instead of calling the lock() and unlock() method.

Regards

Peter

On 16/10/2008, at 2:20 AM, Florijan Stamenkovic wrote:

OK, some more info, perhaps it will strike a chord with someone?

My latest attempt for solving the threading issue was to essentially make every method in my editing context synchronized (though not the old fashioned way, but using a java.util.concurrent.locks.Lock in ec's lock() and unlock() methods) to see if that helps. I've ditched autoLock and autoUnlock, and I simply lock() and unlock() in every overridden method in the ec. Well, I've stopped getting NSRecursiveLock exceptions, but I still get deadlocks. What is weird is that while AWT's event dispatch thread is waiting for the EC lock to be released, the other thread working with the EC is blocking on this line:

EODistributedObjectStore .objectsWithFetchSpecification(EOFetchSpecification, EOEditingContext) line: 499

Obviously, this method is called through the blocking EC, so it has come past the EC lock. So, I'm really wondering what's happening at that line. I've noticed through Eclipse's debugger that the method is synchronized. I am oblivious as to why that thread would block in such a line. If it was on Object.wait() or something there I could understand, but this is bizarre.

Anyone has an idea?

F

On Oct 13, 2008, at 20:14, Mike Schrag wrote:

I don't understand what you say about autoLocking being RR based.
Yep, sorry -- you're right ... Lock coalescing is the one that depends on the RR loop. That said, I definitely ran into cases where auto-locking alone was not enough (at least on the web ... maybe it's less of an issue with JC). What would happen is that you'd have a series of, say, 5 operations that were logically a single transaction, but would be 5 individual lock-unlock autolocks, and there would be changes to the snapshot state inbetween calls that would cause some weird race conditions. This is actually why I decided to do the lock coalescing stuff in Wonder, which seemed to clear up the issues. But not having done JC, maybe this is less of an issue. It only appeared under higher- than-"normal" load.

ms

_______________________________________________
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

_______________________________________________ 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

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.


_______________________________________________ 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:
    • Re: Locking problem
      • From: Florijan Stamenkovic <email@hidden>
References: 
 >Locking problem (From: Florijan Stamenkovic <email@hidden>)
 >Re: Locking problem (From: Mike Schrag <email@hidden>)
 >Re: Locking problem (From: Florijan Stamenkovic <email@hidden>)
 >Re: Locking problem (From: Mike Schrag <email@hidden>)
 >Re: Locking problem (From: Florijan Stamenkovic <email@hidden>)

  • Prev by Date: urgent problem addObjectToBothSides...
  • Next by Date: Re: urgent problem addObjectToBothSides...
  • Previous by thread: Re: Locking problem
  • Next by thread: Re: Locking problem
  • Index(es):
    • Date
    • Thread