a Control that was constructed off the UI thread… Yes, that is a good way to trigger this problem. The underlying problem is caused by the SystemEvents class, it has the unenviable task of raising its events on the correct thread. The UserPreferenceChanged event is the typical trouble-maker, lots of controls subscribe it so they … Read more
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
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
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
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.
I was just fiddling with this issue again in an ASP.NET MVC project. When you want to call async methods from a PartialView, you’re not allowed to make the PartialView async. You’ll get an exception if you do. You can use the following simple workaround in the scenario where you want to call an async … 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