0

if I draw a graph that symbolizes all possible calls to blocking functions (java synchronized methods) and I haven't got any cycle in this graph, can I be sure that deadlocks are imposible. Do petri-nets not work like that?

I am not looking for answers like this: Use some monster framework blahblah.

I want to handle my multithreading with synchronized methodes.

EDIT1: The pointed arrows symbolize if one class calls any synchronized method of another class EDIT2:klick @here the example, showing a cycle

Franz Kafka
  • 10,623
  • 20
  • 93
  • 149

3 Answers3

2

No, that is not enough. Suppose you have to threads: A and B. A calls a method m1 of object o1, which calls method m1 of object o2. Thread B calls method m2 of object o2, which calls method m2 of object o1. Suppose all methods are synchronized. Now, there are concurrent executions of A and B which lead to dead-locks. Although, there is no cyclic call relation between methods.

Is that homework?

Even with your edit regarding class it is not enough, because you can close the cycle through a non synchronized method call.

jmg
  • 7,308
  • 1
  • 18
  • 22
  • Interestingly, if you draw a graph of objects rather than methods, then there is a cycle: o1 -> o2 -> o1. Does that apply to all deadlocks scenarios that don't involve wait/notify? That's probably not an approach which gets you very far in practice, though. – Tom Anderson Apr 01 '11 at 10:30
  • look at the picutre i edited, it shows what tom describes. I m only talking about connections on object level. My first description was wrong... – Franz Kafka Apr 01 '11 at 11:28
  • @Franz Kafka: See, the last sentence of my answer. – jmg Apr 01 '11 at 11:34
0

Some methods might block without a synchronized key word. This applies to many methods in package java.util.concurrent for instance. You should also take into account the synchronized blocks inside methods.

If considering only synchronized methods, you can have deadlocks without cycle in methods calls, as the synchronized methods use the object instance as a monitor. For instance if you have two objects A and B, each one with synchronized methods 1() and 2(). If A.1() calls B.1() and B.2() calls A.2(), although there is no cycle in methods, if a thread calls B.2() at the same time an other calls A.1() then there is a deadlock risk.

Guillaume
  • 5,535
  • 1
  • 24
  • 30
  • Okay I think I explained it wrong. I was talking about drawing a pointed arrow if one class calls another. So arrows are on class level and not methode level. But I only consider drawing arrows if a synchronized class is used. Do you know what I mean? :-) – Franz Kafka Apr 01 '11 at 10:00
0

No. Consider:

private static final Semaphore foo = new Semaphore(1);
private static final Semaphore bar = new Semaphore(1);

private static void one() throws InterruptedException {
    foo.acquire();
    bar.acquire();
    bar.release();
    foo.release();
}

private static void two() throws InterruptedException {
    bar.acquire();
    foo.acquire();
    foo.release();
    bar.release();
}

See http://pastebin.com/QfK5ZByj for a runnable example. It deadlocks pretty quickly for me.

Tom Anderson
  • 46,189
  • 17
  • 92
  • 133
  • Okay this is interesting. If the arrows are lines (pointing in both directions) then it would be a cycle. With single direction arrows it isn't a cycle. – Franz Kafka Apr 01 '11 at 11:35