Writing deadlock-proof code is really hard. Even when you access the tables in the same order you may still get deadlocks [1]. I wrote a post on my blog that elaborates through some approaches that will help you avoid and resolve deadlock situations. If you want to ensure two statements/transactions will never deadlock you may … Read more
The problem you describe is not handled by the database, and from my experience is not entirely handled by Hibernate either. You have to take explicit steps to avoid it being a problem. Hibernate does some of the work for you. As per the previous answer, Hibernate ensures that within an isolated flush the inserts, … Read more
When a thread object goes out of scope and it is in joinable state, the program is terminated. The Standard Committee had two other options for the destructor of a joinable thread. It could quietly join — but join might never return if the thread is stuck. Or it could detach the thread (a detached … Read more
As you never close the ch channel, the range loop will never finish. You can’t send back the result on the same channel. A solution is to use a different one. Your program could be adapted like this : package main import ( “fmt” ) func total(in chan int, out chan int) { res := … Read more
You can do this programmatically using the ThreadMXBean that ships with the JDK: ThreadMXBean bean = ManagementFactory.getThreadMXBean(); long[] threadIds = bean.findDeadlockedThreads(); // Returns null if no threads are deadlocked. if (threadIds != null) { ThreadInfo[] infos = bean.getThreadInfo(threadIds); for (ThreadInfo info : infos) { StackTraceElement[] stack = info.getStackTrace(); // Log or store stack trace information. … Read more
You can use pthread_mutex_trylock. If that succeeds, the mutex was unclaimed and you now own it (so you should release it and return “unheld”, in your case). Otherwise, someone is holding it. I have to stress though that “check to see if a mutex is unclaimed” is a very bad idea. There are inherent race … Read more
Since JDK 1.5 there are very useful methods in the java.lang.management package to find and inspect deadlocks that occurs. See the findMonitorDeadlockedThreads() and findDeadlockedThreads() method of the ThreadMXBean class. A possible way to use this is to have a separate watchdog thread (or periodic task) that does this. Sample code: ThreadMXBean tmx = ManagementFactory.getThreadMXBean(); long[] … Read more
UPDATE: This question was the subject of my blog in January 2013. Thanks for the great question! How can we write a program that will always go into deadlock no matter how the threads are scheduled? Here’s an example in C#. Note that the program appears to contain no locks and no shared data. It … Read more
In the simple case given, unlocking in the reverse order is not necessary to avoid a deadlock. However, as the code gets more complicated, unlocking in the reverse order helps you maintain proper lock ordering. Consider: A.lock(); B.lock(); Foo(); A.unlock(); Bar(); B.unlock(); If Bar() attempts to reacquire A, you’ve effectively broken your lock ordering. You’re … Read more
A lock occurs when multiple processes try to access the same resource at the same time. One process loses out and must wait for the other to finish. A deadlock occurs when the waiting process is still holding on to another resource that the first needs before it can finish. So, an example: Resource A … Read more