Bad programming style

[Richard Teston]

in this example
synchronized method_A()
{
////some code or instructions.....
method_B();
}
synchronized method_B()
{
//some code or instructions.....
}
I've read from previous thread that the example above is bad programming style. If it is? how dose it become a poor style of programming?
I want some clarification. For posted topic before was not clearly answered. Thanks...

[Anonymous]

Normaly method B must not be synchronized, cause you call this method only from a synchronized one.

[John Dale]

If method_A and method_B are in different classes, and hence synchronized on those different classes, this has the potential to create deadlock, the so-called deadly embrace. But you have probably already read about deadly embrace if you are doing multi-thread programming.
Beyond that...
If method_A and method_B are synchronizing on the same object, I don't think there is a reason why the second method "must" not be synchronized. However, if either method is at all complex, it might pose a maintenance problem.
Suppose method_A is expecting that nobody will tinker (or maybe even use) the state of the object while method_A holds the lock. The synchronized keyword on method_B suggest that it too will use or tinker with the state of the object, probably assuming that no other code cares, since method_B knows it's thread holds the lock. You may want to comment both method_A and method_B so that anyone working on the code in the future would be aware that the method does not have exclusive access to the object despite the use of the synchronized keyword.
That's a reason why we might avoid having synchronized routines call synchronized routines.

[Jim Yingst]

I assume both methods are in the same class. If both a() and b() need to be public (or at least non-private), and the additional code in a() requires synchronization just as b() itself does, then this style is appropriate. Otherwise it may be a good idea to make b() private rather than synchronized - if it's only called from a(), and nowhere else, additional synchronization is unnecessary. Or if the extra code in a() does not really need synchronization itself, the sync in b() may be sufficient. It really depends on the application. But it's possible that this code is fine just the way it is.

[Richard Teston]

What i have in mind in synchronized method is... that when synchronized method_A start calling synchronized method_B it will not going to execute another instruction below the instruction that call method_B until it finish executing method_B. Is this correct?
i.e
given these methods were private.
synchronized method_A()
{
step 1 --> //instruction.....
step 2 --> //instruction.....
step 3 --> //instruction.....
step 4 --> method_B
step 8 --> //instruction.....
step 9 --> //instruction.....
}
synchronized method_B()
{
step 5 --> //instruction.....
step 6 --> //instruction.....
step 7 --> //instruction.....
}

[Mr. C Lamont Gilbert]

Originally posted by Richard Teston:
What i have in mind in synchronized method is... that when synchronized method_A start calling synchronized method_B it will not going to execute another instruction below the instruction that call method_B until it finish executing method_B. Is this correct?
i.e
given these methods were private.
synchronized method_A()
{
step 1 --> //instruction.....
step 2 --> //instruction.....
step 3 --> //instruction.....
step 4 --> method_B
step 8 --> //instruction.....
step 9 --> //instruction.....
}
synchronized method_B()
{
step 5 --> //instruction.....
step 6 --> //instruction.....
step 7 --> //instruction.....
}

This is always the case, with or without synchronization. A thread of execution can only execute one instruction at a time. It cant both execute methodB and finish out A at the same time. A will be finished after B returns.