Heteroclinic.net logo

www.heteroclinic.net

Advanced Concurrency Topic:
Runtime Deadlock Detection I
Deadlock can be a nightmare, but when it happens, we may not notice it. It may be burried deep in the vast quantity of process/thread instances. Nothing is shown in the GUI, nothing is written in your log. Some programs may behave strangely, you may notice or not. We did some experiments, code hacking. Finally, under the very limited conditions of our experiment, we found such deadlocks are detect-able. Thus, we may provide some remedy. Our knowledge and understanding may be partial, in-complete even wrong. Please do not hesitate to point out them.

Here we choose Java because Java is so convenient to deploy such an application. Other programming languages should be sufficient too. Our mission is to study/understand the deadlock phenomenon not to debate the features of different languages.

The beginning part requires you set up the following Java program in a same package. For convenience, I used the latest JDK and the latest Eclipse IDE.

Util.java

Indy.java

FindRaceCondition.java

By change the two lines in `FindRaceCondition.java', we did some experiments.

Finally when we set

The deadlock is almost certain to happen. Please notice we say almost. In concurrency programming, nothing is certain (but statistically high probability).

Advanced Concurrency Topic:
Runtime Deadlock Detection II
Now we put two new files, if you change the value of the last argument of ThrottledIndy's constructor in file `DeadlockThrottle.java'. You will see deadlock may not be certain. Our experiments shows another mis-understanding that even every method is synchronized, it is still not safe -- at least, deadlock may happen.

DeadlockThrottle.java

ThrottledIndy.java

Here are the results that are not certain:

Advanced Concurrency Topic:
Runtime Deadlock Detection III
We found Indies like to be alone almost all the time, otherwise, the results are really unpredictable or not what we want. So we design a class Duo. First, Duos should be able to do Indy's job. We also put class Resource to a separate file. The experiments is executed from the main of `TestDuoDeadlockableVersion.java'. You will find Duo behave the same as Indy.

Duo.java

Resource.java

TestDuoDeadlockableVersion.java

Advanced Concurrency Topic:
Runtime Deadlock Detection IV
DeadlockException
We did a lot of code hacking to simulate the intrinsic lock of Java Object class. The final result is under our confining box, deadlock is detected, and the late thread yield the resource to the early thread. Please note there may be implementation that is wrong, you can find the remarks I put.

After we give some training to Duos, it seem they are able to handle a situation we don't want to get into. Please notice the difference of Duo and TrainedDuo. The parameter in duowait(long) for example, is 0 for Duo, value greater than 1 for TrainedDuo. Finally, we want to talk something about topology. Topology is not a secret world jargon. It simply means the way to represent connections of different entities in a space. I once try to do some visualization. We have thread, resource, and time. It is a three-dimensional world thus the diagram is not easy to plot. However, if you deal with computer graphics, you won't be strange to edge pair. With the aiding of edge pairs, we can traverse a connected simplex, may we call it a manifold.

The starting function main is in file `TestTrainedDuo.java'.

A result that is still not certain to get

DeadlockException.java

TrainedDuo.java

TestTrainedDuo.java