OK. Thanks for the explanation. It's probably the case in general, but in all of my tests (>10), process 2 always aborts. I don't think it is arbitrary in this example, or could it be?
2010/8/20 Greg Stark <gsst...@mit.edu> > On Fri, Aug 20, 2010 at 7:38 PM, Joel Jacobson <j...@gluefinance.com> > wrote: > > If the locking logic would be modified to allow process 2 to go through, > and > > instead abort process 1, I understand some other scenarios would of > course > > be affected, where the situation would be handled in a less optimal way. > > Which process dies when there's a deadlock is pretty much arbitary. > The first process to notice the deadlock will just throw an error > itself. Which one notices first depends on the timing of when the > blocking locks were taken. > > If the second process to get stuck blocks before the first process > checks then the first process will notice first. If it does other > stuff first then the first process will check, not find a deadlock and > go back to sleep. Then the deadlock won't be detected until the second > process checks. > > -- > greg > -- Best regards, Joel Jacobson Glue Finance E: j...@gluefinance.com T: +46 70 360 38 01 Postal address: Glue Finance AB Box 549 114 11 Stockholm Sweden Visiting address: Glue Finance AB Birger Jarlsgatan 14 114 34 Stockholm Sweden
