(dead)locking of EC and OSC
(dead)locking of EC and OSC
- Subject: (dead)locking of EC and OSC
- From: Marc Guenther <email@hidden>
- Date: Fri, 23 Jul 2010 14:08:07 +0200
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!
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
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?
- What do we do about it?
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. Which in turn, causes all these ECs to be locked. Which violates the rule.
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.
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.
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