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

Visiting address:
Glue Finance AB
Birger Jarlsgatan 14
114 34 Stockholm

Reply via email to