Re: (dead)locking of EC and OSC
Re: (dead)locking of EC and OSC
- Subject: Re: (dead)locking of EC and OSC
- From: Chuck Hill <email@hidden>
- Date: Fri, 23 Jul 2010 07:55:01 -0700
On Jul 23, 2010, at 5:08 AM, Marc Guenther wrote:
> Hi,
>
> We recently had some deadlock problems involving EC and OSC locking, and I would like to validate my thoughts with the list.
>
> As a very basic rule with everything multithreaded, whenever two threads want access to the same resources, they have to lock them in a predefined identical order. Otherwise you have that classic deadlock possibility, where T1 has A and wants B, and T2 has B and wants A.
>
> This, for EOF, means the following:
>
> Whenever you hold an OSC lock, you are NOT allowed to lock any EC anymore!
I think of it as taking escalating locks: EC -> DB Context -> OSC
> Why not? Cause the normal order is the other way round. First you lock the EC, then, when doing something with it, you lock the OSC.
>
> For example, our specific deadlock occurred, cause we had a Thread1:
> - lock the OSC
> - in a loop, do some operations involving locking of lots of ECs
> (we have some stuff in there, which posts notifications to all ECs)
> - Unlock OSC
That seems like a long time to have the OSC locked. Why are you locking the OSC?
> Now, while T1 was busy in its loop, some T2 was fetching a single EO:
> - lock the EC
> - fetch EO causing OSC to lock
> -> which waits for T2 to finish
>
> And, as soon as the T1 loop reaches the locked EC of T2
>
> -> Deadlock
>
>
> Now, the questions I have:
> - Is this analysis correct?
Yes.
> - What do we do about it?
Lock in the correct order. Don't lock and hold locked the OSC. Use different EOF stacks (hence different OSC). Don't touch the same EC in more than one thread concurrently.
> If I understand all this correctly, my above rule means:
>
> _Whenever you have the need to explicitely lock an OSC, you can't do any operation, which would cause an formerly unlocked (by you) EC to be locked._
>
> Which might be more than you think. IIRC, you are not allowed to make any changes to any EO. Because that causes EOObjectsChangedInStoreNotifications to be fired around to all ECs.
That happens when saveChanges() is called. saveChanges() locks the OSC.
> Which in turn, causes all these ECs to be locked. Which violates the rule.
If they are already locked, it will only queue the notification, not wait for a lock.
> Now, if you really need to do this (you NEED to lock an OSC, and you NEED to use ECs while having it locked), you could think, Oh it's OK, I just lock all of them first. But then again, in what order do you lock the ECs? Because if you do it in random order, you again have the possibility of deadlock.
That sounds like you may be sharing ECs between threads in a dangerous pattern.
> So, what is everybody doing?
> - I don't lock the OSC myself. Why would I want to?
> - I do, but I am VERY careful about what I do with it being locked.
> - I do, and so far I have been lucky.
Never any problems, provided you lock it at the appropriate time.
Chuck
> BTW, this deadlock we had occurred about once a week. As such, it was not really reproducible on a developer machine. We finally catched it, when we put that T2 thread in an endless loop, letting it refetch that same EO again and again. The Eclipse Console didn't like the logging output of that thread at all :)
>
> Greetings,
> Marc
>
> _______________________________________________
> 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
--
Chuck Hill Senior Consultant / VP Development
Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems.
http://www.global-village.net/products/practical_webobjects
Attachment:
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
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