aspose file tools*
The moose likes Threads and Synchronization and the fly likes please explain me why this program is not going into deadlock scenario Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "please explain me why this program is not going into deadlock scenario" Watch "please explain me why this program is not going into deadlock scenario" New topic
Author

please explain me why this program is not going into deadlock scenario

Saikrishna Vemuri
Greenhorn

Joined: Mar 01, 2012
Posts: 15



[HENRY: Added Code Tags]
Henry Wong
author
Sheriff

Joined: Sep 28, 2004
Posts: 18982
    
  40

Saikrishna Vemuri wrote:


Your two threads are using different locks.... two threads with four locks (two locks each).

Henry
Saikrishna Vemuri
Greenhorn

Joined: Mar 01, 2012
Posts: 15
ohhh.. Okay
but now i 'll modify it as

Lockclas1 l1=new Lockclas1();
Lockclas2 l2=new Lockclas2();
new deadlock1(l1,l2);
new Deadlock(l1,l2);

now can i say the program is in deadlock
Thanks in Advance
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Saikrishna Vemuri wrote:ohhh.. Okay
but now i 'll modify it as

Lockclas1 l1=new Lockclas1();
Lockclas2 l2=new Lockclas2();
new deadlock1(l1,l2);
new Deadlock(l1,l2);

now can i say the program is in deadlock
Thanks in Advance


I don't know.

It seems you're overcomplicating it. I don't even want to read your code because a) there's too much of it, b) the indenting is inconsistent and makes it hard to read, and c) the above described change doesn't really make sense, and d) I don't want to have to try to imagine your code as some baseline with some particular change.

If you want to demonstrate deadlock, here's a simpler program that does it:

Saikrishna Vemuri
Greenhorn

Joined: Mar 01, 2012
Posts: 15
Your program is too Simple . i agree with you i've made it look like a complicated program
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Saikrishna Vemuri wrote:Your program is too Simple .


Too simple in a good way or in a bad way?

If a bad way, in what way does it not meet your requirements? What problem are you still trying to solve or what question do you still have?
Saikrishna Vemuri
Greenhorn

Joined: Mar 01, 2012
Posts: 15
hey nthng lyk . you program absolutely met my requirements
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Saikrishna Vemuri wrote:hey nthng lyk . you program absolutely met my requirements


Great! Glad I could help.
Saikrishna Vemuri
Greenhorn

Joined: Mar 01, 2012
Posts: 15
Oops i got struck in middle
i need a clarity .. when Thread-0 Object is executing in synchronized area how Thread-1 got access to it? I heard that sleep() doesn't release d lock is it so ? then how it is possible for Thread-1 to get access to other object lock area?

Dont mind of my doubts i'm just a beginner .!
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Saikrishna Vemuri wrote:Oops i got struck in middle
i need a clarity .. when Thread-0 Object is executing in synchronized area how Thread-1 got access to it? I heard that sleep() doesn't release d lock is it so ? then how it is possible for Thread-1 to get access to other object lock area?


I'm not quite sure what you're asking.




Are you asking how we can have both output 1 and output 2, since output 1 indicates a lock has already been acquired? If that's your question, then the reason is the same reason your original code didn't show deadlock: T0 is getting the lock for the A object and T1 is getting the lock for the B object. You need to understand that syncing doesn't mean "No other thread can enter any sync block or method." Rather, it means "No other thread can enter any sync block or method that syncs on the same lock I currently hold. Each object has its own lock.

OR...

Are you asking how we can get to output 3, since T0 already holds the lock for object A? If this is what you're asking, then the answer is to look closely at the code and note that that line is printed out right before we enter the sync block. And note that output 3 and output 4 are where the threads get stuck. They never get to "T1 GOT IT A" and "T0 GOT IT B" because of the deadlock.

Remember, the conditions for a deadlock are 1) two (or more) different threads each hold a resource that the other one wants, and 2) neither thread can release the resource it currently holds until after it obtains the one the other one holds.

Saikrishna Vemuri
Greenhorn

Joined: Mar 01, 2012
Posts: 15
hmmm.. my doubt is related to first paragraph and you made it clear that " two threads on same object " .. Thankq
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Saikrishna Vemuri wrote:hmmm.. my doubt is related to first paragraph and you made it clear that " two threads on same object " .. Thankq


You're welcome.

So, just to be clear, you understand that each Object has its own lock?

And you understand that whenever the keyword synchronized appears, that tells our code to acquire the lock for exactly one object (waiting until the lock is released if another thread currently holds it), and has no relation to any other locks?

Saikrishna Vemuri
Greenhorn

Joined: Mar 01, 2012
Posts: 15
Ya.. from mrng onwards i'm fighting over it.. getting confused . And now you made it clear its Object level lock,
Praveen Kumar M K
Ranch Hand

Joined: Jul 03, 2011
Posts: 256
Just to clarify Krishna, there is no such thing as object level lock or class level lock.

JLS -
A synchronized method acquires a monitor (§17.1) before it executes. For a class (static) method, the monitor associated with the Class object for the method's class is used. For an instance method, the monitor associated with this (the object for which the method was invoked) is used.
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Praveen Kumar M K wrote:Just to clarify Krishna, there is no such thing as object level lock or class level lock.

JLS -
A synchronized method acquires a monitor (§17.1) before it executes. For a class (static) method, the monitor associated with the Class object for the method's class is used. For an instance method, the monitor associated with this (the object for which the method was invoked) is used.


Right. It's simply that every object has a lock associated with it. Obtaining that lock (by entering a sync block) doesn't "lock the object." It just prevents other threads from obtaining that same lock. The other threads are still able to do whatever they want with that object that's not explicitly synchronized on that lock.
Saikrishna Vemuri
Greenhorn

Joined: Mar 01, 2012
Posts: 15

JLS -
A synchronized method acquires a monitor (§17.1) before it executes. For a class (static) method, the monitor associated with the Class object for the method's class is used. For an instance method, the monitor associated with this (the object for which the method was invoked) is used.



Then why the words class level and Object level came into existent ?
Jeff Verdegan
Bartender

Joined: Jan 03, 2004
Posts: 6109
    
    6

Saikrishna Vemuri wrote:
JLS -
A synchronized method acquires a monitor (§17.1) before it executes. For a class (static) method, the monitor associated with the Class object for the method's class is used. For an instance method, the monitor associated with this (the object for which the method was invoked) is used.



Then why the words class level and Object level came into existent ?

Those phrases don't actually mean anything. There are no different "levels" of locks. The phrases probably came into existence from people thinking that a static synchronized method was somehow different from a non-static synchronized method. For get about phrases like "class level lock" and "object level lock"--there is no such thing.
 
jQuery in Action, 2nd edition
 
subject: please explain me why this program is not going into deadlock scenario