www.heteroclinic.net
Runtime Deadlock Detection XXV A Bad Prototype How to: You would need these two jars: and 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. |
||
Runtime Deadlock Detection XXVI An Artificial Livelock You would need these two jars: and 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. |
||
Runtime Deadlock Detection XXVII More Tested Examples How to: Entry point: Fast How to: Entry point: Random How to: Entry point: |
||
Runtime Deadlock Detection XXVIII Period Today, we release - 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 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. |