This week's book giveaway is in the OO, Patterns, UML and Refactoring forum. We're giving away four copies of Refactoring for Software Design Smells: Managing Technical Debt and have Girish Suryanarayana, Ganesh Samarthyam & Tushar Sharma on-line! See this thread for details.
Anudeep Duvvuri wrote:So it means that when we acquire a lock on sub class object we implicitly lock the super class. Is this right? correct me if I am wrong
No, he is saying that you lock the Object, not the class so super class and sub class does not come into play. So in your example you actually have 2 objects. You have an instance of Lock2 which has a synchronized lock1() method. You also have a different Object which is an instance of Lock1 which has an unsymchronized lock1() method. By making Lock2.lock1() synchronized you do not affect the Lock1.lock1() method at all. In addition, if you made Lock1.lock1() synchronized, then the two methods would not be mutually exclusive be you have two different Objects and therefor different locks.
I'm saying that refering to locking a "class" is misleading. You lock an object, and that affects all code that is synchronized on that object. That may include methods that are defined in a superclass, if they synchronize on this.
Even that terminology is inaccurate, or at least misleading, IMHO. It makes it sound like you're denying all access to that object, when that's not what's happening. I think it's more accurate to say we lock a block or method on an object, or just that we obtain an object's lock.
I’ve looked at a lot of different solutions, and in my humble opinion Aspose is the way to go. Here’s the link: http://aspose.com