On 1/3/07, Howard Chu hyc@symas.com wrote:
matthew sporleder wrote:
After reading http://www.oracle.com/technology/documentation/berkeley-db/db/ref/lock/max.h...
I started to look at db_stat -c and noticed this: 5203 Total number of locks not immediately available due to conflicts. 15 Number of deadlocks.
Any hints as to why I would have deadlocks, or locks not available? Maybe I'm misreading what a conflict is vs just contention.
Thanks, _Matt
(.. if only I knew what the conflict matrix was trying to say ;) .
All of that is normal. A lock conflict occurs whenever two different threads try to lock the same object, using incompatible modes. The conflict matrix tells you which modes are compatible. E.g., a read lock is compatible with other read locks, but not with a write lock. So if one thread already has a write lock on an object, any other thread that tries to get a read lock on the same object will conflict. The BDB lock subsystem supports a lot of other modes as well, but we don't use them explicitly; they're mainly used internally in the BDB library.
Deadlocks are a pretty much unavoidable occurrence when you have multiple threads active, obtaining multiple types of locks at the same time. We try to acquire resources in a consistent order to minimize them, but there's a lot of lock activity happening inside the BDB library that we have no direct control over. It's not a big deal; the code retries automatically when a deadlock occurs.
Thanks for the re-assurance.