If you are using InnoDB or any row-level transactional RDBMS, then it is possible that any write transaction can cause a deadlock, even in perfectly normal situations. Larger tables, larger writes, and long transaction blocks will often increase the likelihood of deadlocks occurring. In your situation, it’s probably a combination of these. The only way … Read more
In Java, each Object provides the ability for a Thread to synchronize, or lock, on it. When a method is synchronized, the method uses its object instance as the lock. In your example, the methods bow and bowBack are both synchronized, and both are in the same class Friend. This means that any Thread executing … Read more
I found a bug report of a very similar case (JDK-8143380) which was closed as “Not an Issue” by Stuart Marks: This is a class initialization deadlock. The test program’s main thread executes the class static initializer, which sets the initialization in-progress flag for the class; this flag remains set until the static initializer completes. … Read more
No, not as long as you are locking on the same object. The recursive code effectively already has the lock and so can continue unhindered. lock(object) {…} is shorthand for using the Monitor class. As Marc points out, Monitor allows re-entrancy, so repeated attempts to lock on an object on which the current thread already … Read more
The difference between a recursive and non-recursive mutex has to do with ownership. In the case of a recursive mutex, the kernel has to keep track of the thread who actually obtained the mutex the first time around so that it can detect the difference between recursion vs. a different thread that should block instead. … Read more
One easy trick that can help with most deadlocks is sorting the operations in a specific order. You get a deadlock when two transactions are trying to lock two locks at opposite orders, ie: connection 1: locks key(1), locks key(2); connection 2: locks key(2), locks key(1); If both run at the same time, connection 1 … Read more
Acquiring a value via an async method: var result = Task.Run(() => asyncGetValue()).Result; Syncronously calling an async method Task.Run( () => asyncMethod()).Wait(); No deadlock issues will occur due to the use of Task.Run.
Take a look at this example, Stephen has a clear answer for you: So this is what happens, starting with the top-level method (Button1_Click for UI / MyController.Get for ASP.NET): The top-level method calls GetJsonAsync (within the UI/ASP.NET context). GetJsonAsync starts the REST request by calling HttpClient.GetStringAsync (still within the context). GetStringAsync returns an uncompleted … Read more
Wait and await – while similar conceptually – are actually completely different. Wait will synchronously block until the task completes. So the current thread is literally blocked waiting for the task to complete. As a general rule, you should use “async all the way down”; that is, don’t block on async code. On my blog, … Read more