Heteroclinic.net logo

www.heteroclinic.net

Advanced Concurrency Topic:
Runtime Deadlock Detection XXV
A Bad Prototype
Here, we present a bad prototye. We also give some reasons to present it even it is bad.
How to: You would need these two jars: and treetorplus3.jar and jdfrbadprototype01.jar.
You can study the source code inside jdfrbadprototype01.jar. You can also check out the entry point TwoLayersDeadlockImprovisedSolution.java. Why it is bad?
Simply, it does not full-fill the purpose of the desgin or the requirement(s). In "Advanced Concurrency Topic: Runtime Deadlock Detection XIX Visualization of an Imaginary Concurrency Event" and "Advanced Concurrency Topic: Runtime Deadlock Detection XX Visualization Results of XIX", I drew a series of diagrams. We tried to conjecture a scheduler that creates a live-lock. Two threads keep yielding each other, but neither of them can acquire all the resources it needs. Neither of them can finish its job.
To build this prototype, we made an assumption. It was also made from the beginning I dived into the dead-lock detection topic. The assumption is that we would be able to read one thread's status from another thread. Thus, we can detect deadlock. Live-lock is construct-able if a thread can know what its peer thread trying to get. If it just gives up one but not all the peer needs, live-lock could happen.
From this prototype, we know this assumption is wrong. If we execute the command line given, it will create either a dead-lock or the starvation of one of the threads. A thread's status is so volatile. A running thread will be blocked, go to sleeping, or perished. A blocked thread can be unblocked just next several CPU ticks. One thing is certain if a thread had finished. We may say two threads are like two particles, can this be called 'entangling', to observe accurately will affect the behavior the object being observed. Or to say, we can describe space/status or time accurately either of them but not both of them at the same time. I am not in physics area, so I stop short here and come back to our topic.
So if we can not read another thread's status from one thread, which is a fundamental mis-understanding, are we completely wrong so we can do nothing( we may also argue that we can lock status, a thread status has read write lock etc-- nightmare of spaghetti)? In our previous discussion, we show a healthy system is a tree-like structure. When a dead-lock is formed, it becomes a cyclic graph. But once the dead-lock is formed, no threads can change their status, suppose we use a no-time-out lock(). What we did in the middle of this topic, help us properly construct the graph. When dead-lock happens, we can detect it. The profiling or detecting mission is accomplished.
Advanced Concurrency Topic:
Runtime Deadlock Detection XXVI
An Artificial Livelock
Although our attempt at XXV failed, we can still make a scheduler that follows the digram we drew.
You would need these two jars: and treetorplus3.jar and jdfr1.0.jar.

How to: You can check out the entry point: So, you would see the concern is no longer to create a live-lock. At the end of each thread, we did something. I hope this will provide some hint about how to deal with concurrent program that looks bizzare. In general, we should not fear live-lock. As long as the threads are alive, we will have a chance to change the resource access pattern. If a system has no hope, that is the real problem.

20130122artificial_live_lock.gif

Advanced Concurrency Topic:
Runtime Deadlock Detection XXVII
More Tested Examples
Multi-tier

201301PROF_MUTLTI_TIER.gif

How to:
Entry point: Fast
How to:
Entry point: Random
How to:
Entry point:
Advanced Concurrency Topic:
Runtime Deadlock Detection XXVIII
Period
So far, months have been spent upon this topic. The resources are limited, I have to put a period. We may continue on with the same topic or similiar topic.

Today, we release jdfr1.0.jar.
- it fully supports Java ReentrantLock
- it has several proto-types, quick-starts or just say examples -- in the Blog section

It will be a very useful tool to profile concurrent programming. We also have treetor treetorplus3.jar which can render about several thousands nodes of a-cyclic graph or a forest. If I got enough support, we may switch to OpenGL rendering engine and using more advanced IPC.

We corrected some mis-understandings. They are critical but finally not fatal to this project.
I am still not sure about next step. I hope there will be more people download and study what I did. It will be a great pleasure that you can achieve something with these tools. Science and technology does not rely on luck. If you find any bug or errors, please feel free to point them out. This project is done by one person, so it is convenient to control. In real life projects, we have to resolve human conflicts, legacy pacakges etc. Some time you do not even have the source code not mention how to modify them. So we can not simply put a easy or difficult label for a project.
The methods we tried or proposed, may be helpful while extending to profile database system, interprocess concurrent programming, the operating system, or for clustered computing units. Concurrent programming in some sense destroyed the von Neuman architecture, much more effort is needed for understanding or utilizing the nature of concurrency.