• Post Reply Bookmark Topic Watch Topic
  • New Topic
programming forums Java Mobile Certification Databases Caching Books Engineering Micro Controllers OS Languages Paradigms IDEs Build Tools Frameworks Application Servers Open Source This Site Careers Other all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Ron McLeod
  • Paul Clapham
  • Bear Bibeault
  • Junilu Lacar
Sheriffs:
  • Jeanne Boyarsky
  • Tim Cooke
  • Henry Wong
Saloon Keepers:
  • Tim Moores
  • Stephan van Hulst
  • Tim Holloway
  • salvin francis
  • Frits Walraven
Bartenders:
  • Scott Selikoff
  • Piet Souris
  • Carey Brown

synchronization

 
Ranch Hand
Posts: 649
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
deadlock example

again I am stuck in synchronization
please explain me why is it deadlock
thank you
 
Rancher
Posts: 904
22
Netbeans IDE Oracle MySQL Database Tomcat Server C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
OK, I will share my thoughts, and probably ignorance, here with you:

You have in your object 2 methods which have reference to external objects "instantiated" from the same class, Friend. So in your bow you initiate a bowback. I put instantiated in quotes because you have a static object, from your static inner class, so your object is in reality only one object, so you have reference to it, as you try to initiate another action in that same object. In doing so, the first action cannot complete, the bow, so that you can get to a stable state asked for in the synchronize so your bowback can complete.

So you are stuck in the bow, as you wait for the bowback which has to wait for the bow.

OK, there is my 2 cents... anyone else?
 
Puspender Tanwar
Ranch Hand
Posts: 649
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you morgan, but your explanation is quite typical and confusing to understand !
 
Les Morgan
Rancher
Posts: 904
22
Netbeans IDE Oracle MySQL Database Tomcat Server C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Les Morgan wrote: ... you have a static object, from your static inner class, so your object is in reality only one object ...



"static" is frequently used, and rarely gives the result intended by the programmer that chose to use it. "static" is like a wormhole in space tying all the points along the way in one. You can create 1000's of objects from the Deadlock class, but common to all of those, is the one, static, Friend object. Rather than having 1 Friend in each Deadlock object, you have one Friend object which is commonly referenced in all of your Deadlock Objects.
 
Les Morgan
Rancher
Posts: 904
22
Netbeans IDE Oracle MySQL Database Tomcat Server C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Les Morgan wrote: Rather than having 1 Friend in each Deadlock object, you have one Friend object which is commonly referenced in all of your Deadlock Objects.



So when you ask the object to be synchronized, you are asking it to wait for itself as you make your bowback call from your bow--the object referencing itself is blocking itself from being synchronized.
 
Les Morgan
Rancher
Posts: 904
22
Netbeans IDE Oracle MySQL Database Tomcat Server C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Even if we change the code to:

Which gets rid of the static inner class, we still have the problem with bowBack being called from bow resulting in a block, this code was specifically designed for the code trail to illustrate blocking, even though, you have used synchronized correctly. You have to let bow complete before calling bowBack to get rid of the blocking scenario.
 
Puspender Tanwar
Ranch Hand
Posts: 649
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hey Morgan, exactly I was going to reply... leave about the static class.. just explain me how this code is a deadlock
would appreciate if you explain it step wise
Thank you
 
Les Morgan
Rancher
Posts: 904
22
Netbeans IDE Oracle MySQL Database Tomcat Server C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator

Puspender Tanwar wrote:hey Morgan, exactly I was going to reply... leave about the static class.. just explain me how this code is a deadlock
would appreciate if you explain it step wise
Thank you



Got it. First off, let's reiterate that this code came from the Java Trail, a fact that I did not see right off, and it is designed to block. If you put the code in your IDE you see that both threads bow to each other, but then nothing... it just keeps on running forever. That is because as execution from both threads comes into the object as it was written for the Java Trail, there isn't any resources to guard, no variables to misread, so they both come into the bow method, but now you are inside a synchronized block, and in that block both objects want to access a method that is marked as synchronized. When that happens Java takes over and says--nope--you both cannot simultaneously access a method that is synchronized (because now it's executing inside a synchronized block and synchronized calls are expected to be sensitive). So we have a problem, no locks can be issued until one requester expires. Well that is not going to happen because neither has a timeout, so both threads are now sitting in the bow, progressed through the bow state and trying to get a lock on bowBack, but neither can because they are simultaneously requesting a synchronized call from a synchronized block. The problem has to be worked out through some other means than just marking the block as synchronized: synchronized does not guarantee a resource, it guarantees multiple resources will not change/access sensitive segments of code simultaneously.

If we make this change:

Notice no more static, and also no more synchronized blocks because each thread is executing a separate Friend object, there isn't a race condition and you get completion of both threads, but you cannot guarantee which thread will finish first as written.


 
Les Morgan
Rancher
Posts: 904
22
Netbeans IDE Oracle MySQL Database Tomcat Server C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Notice that if you put the "synchronized" block back in, even with the separate objects, you get the same blocking condition. "synchronized" has a class scope effect, so when you hit that code segment, you are being synchronized across all objects. I believe they do this just incase there are static elements down in your code.
 
Puspender Tanwar
Ranch Hand
Posts: 649
2
Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
thank you morgan
could you tell that , if there are two threads , on what condition the second thread got the chance if first is running. I mean, like the second thread got the chance when the method called by thread1 is over, or it encounters a wait() or it encounters a return.(hope you understand what I am trying to saying )
what are the conditions when thread2 get the chance by stopping the thread1
 
Les Morgan
Rancher
Posts: 904
22
Netbeans IDE Oracle MySQL Database Tomcat Server C++ Java
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you manually kill one of the threads, the other will complete, but also if you have built a monitor into your app--a timer that checks progress of your application--then you can have it do a random time wait on the thread. I say a random time wait, because both threads are in a tie condition, so they will both be caught by a monitor, so if they both wait the same amount of time, then they will both reactivate to the same tie condition. Which ever thread wakes first, gets to complete first, and then when the second thread wakes, it will have its chance to complete too.

Puspender Tanwar wrote:thank you morgan
could you tell that , if there are two threads , on what condition the second thread got the chance if first is running. I mean, like the second thread got the chance when the method called by thread1 is over, or it encounters a wait() or it encounters a return.(hope you understand what I am trying to saying )
what are the conditions when thread2 get the chance by stopping the thread1

 
Alas, poor Yorick, he knew this tiny ad:
Building a Better World in your Backyard by Paul Wheaton and Shawn Klassen-Koop
https://coderanch.com/wiki/718759/books/Building-World-Backyard-Paul-Wheaton
    Bookmark Topic Watch Topic
  • New Topic