I'm confused about checkin 1879: "Do not invoke the busy callback when
trying to promote a lock from SHARED to RESERVED. This avoids a
deadlock."
Consider two threads that are deadlocking. Thread A has made changes,
and is preparing to commit, so promotes its lock from reserved to
pending. Thread B begins making changes, and wants to promote its lock
from shared to reserved. At that point, no more progress can be made.
Thread A can't go from pending to exclusive because B still has a shared
lock. Thread B can't go from shared to reserved because Thread A has a
pending lock.
My experience with the code up to 3.0.3 is that both thread A and B will
begin calling the busy handler. I've written my application so that my
busy handler can choose which thread to force to rollback, using
application-specific knowledge about the precedence of the threads (UI
threads are given preference, and background threads roll back). It may
happen that thread A is actually a background thread, so even if it has
the more advanced lock, I will choose to roll it back, letting thread B
continue on.
With the change in checkin 1879, it looks like my busy handler doesn't
get a chance to make a choice any more. Now thread B immediately gets a
BUSY error, without invoking the busy handler.
Personally, I was very pleased that the busy handler allowed me so much
control. I can see the other side of the argument: for users who don't
want to be bothered implementing a fancy busy handler, the fewer
deadlocks the better. My application will continue to work (because all
threads are prepared for deadlock errors), but I liked being able to
make an intelligent choice.
Wouldn't it be better to invoke the busy handler in all cases? Have I
gotten something wrong?
--Ned.
http://nedbatchelder.com
