If you are using monitors in your concurrent system design, is this sufficient to prevent deadlock? I know that in Java there are many ways to cause deadlock, but few of these examples are actually to do with monitors (most use mutexes).
            Asked
            
        
        
            Active
            
        
            Viewed 1,072 times
        
    -2
            
            
        - 
                    You can get deadlocks, and although hard to reproduce they will get you eventually (sometimes years later when you update a JVM, OS, or hardware) – Peter Lawrey May 03 '16 at 16:36
 
1 Answers
-1
            
            
        Deadlock can occur, but you are quite unlikely to have this happen by accident, I spent 10 minutes thinking up a horrible corner case.
In the following code, note that removing "synchronized" will cause it to terminate.
public class Foo implements Runnable {
    private Foo target;
    private int count;
    synchronized void go(int n) {
        try {
            if (n < 1) {
                System.out.println("Got to the bottom.");
            } else {
                Foo f = new Foo();
                f.target = this;
                f.count = n;
                Thread t = new Thread(f);
                t.start();
                t.join();
            }
        } catch (InterruptedException e) {
            // Demo
        }
    }
    @Override
    public void run() {
        target.go(count-1);    
    } 
    public static void main(String[] args) {
        new Foo().go(1);
    }
} 
        N. McA.
        
- 4,796
 - 4
 - 35
 - 60
 
- 
                    This might demonstrate a deadlock, but it is a very poor example of writing multithreaded code. You're creating a `Foo` instance to start and join on a thread created from a new `Foo` instance within the origin `Foo` instance...It's quite upside down. – Sotirios Delimanolis May 03 '16 at 16:36
 - 
                    Basically, don't `start` a thread within your `Runnable` implementation if that thread is meant to run that `Runnable` implementation. – Sotirios Delimanolis May 03 '16 at 16:43
 - 
                    @SotiriosDelimanolis -> Yeah it's very bad code. It was just intended as an example to demonstrate that the monitor system, even ignoring considerations of signal/wait, is vulnerable to deadlock. I posted it because several high ranking results from google had *terrible* answers that instead demonstrated that mutexes could cause deadlock. – N. McA. May 03 '16 at 18:17