• 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 Pie Elite all forums
this forum made possible by our volunteer staff, including ...
Marshals:
  • Campbell Ritchie
  • Jeanne Boyarsky
  • Ron McLeod
  • Paul Clapham
  • Liutauras Vilda
Sheriffs:
  • paul wheaton
  • Rob Spoor
  • Devaka Cooray
Saloon Keepers:
  • Stephan van Hulst
  • Tim Holloway
  • Carey Brown
  • Frits Walraven
  • Tim Moores
Bartenders:
  • Mikalai Zaikin

synchronization and locks

 
Ranch Hand
Posts: 330
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi all. In the code below t has a lock on l object when it enters the synchronized method1 at line 22(or at least thats what I think) and then waits at line 25. But how come t2 was able to execute method2 at line 31 which is also a synchronized method? My understanding (based on the K&B book) is that every object in Java has a built-in lock that only comes into play when the object has synchronized method code. Since there is only one lock per object, if one thread has picked up the lock, no other thread can enter the synchronized code (which means any synchronized method of that object) until the lock has been released.

However, modifying the code a bit to use sleep in lieu of wait at line 25 does lock the object. How is it that lock works if I use sleep and not for wait?

Thanks.
 
Ranch Hand
Posts: 504
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Hi, calling wait() on an object instance sends a currently executing thread to a waiting pool while making it relinquish the lock on this object. After this point, if another thread attempts to enter the code that is sync-ed on the same object, it'll succeed. In your example, it's method method2(). Calling notify() lets a waiting thread know that the lock on the object it's blocked on is about to be released soon (but not right away). So, while thread 1 is blocked, the lock becomes available to thread 2. Notice, however, that nothing is guaranteed flow wise in your first example. If thread 2 is chosen to run first, the program will never complete blocking in method1()!
The second example uses Thread.sleep() to put a currently executing thread (obviously, thread 1) to sleep. While sleeping, a thread retains all its locks, so there's no way that thread 2 completes if thread 1 started first. And again, nothing is guaranteed by the scheduler. Thread 2 may run before thread 1.
 
dennis zined
Ranch Hand
Posts: 330
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Awesome. Thanks Vad.
 
dennis zined
Ranch Hand
Posts: 330
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
I just found out I can lock just a portion of my method as opposed to the entire object. Line 29 uses the lock of another object rather than use its own. That other object is declared static on line 18 so that no two threads can lock on the same piece of code otherwise using synchronize would be useless. So while that portion is locked other threads can also lock the same object using the object's own lock or again use some other object's lock.
I'm just blown away on how powerful thread stuff is. Would anybody know a good book on good multi-threaded design?
 
Vad Fogel
Ranch Hand
Posts: 504
  • Mark post as helpful
  • send pies
    Number of slices to send:
    Optional 'thank-you' note:
  • Quote
  • Report post to moderator
Dennis, what you've mentioned above is a popular programming technique - synchronizing on a dummy object. It's got its own pros and cons, and that discussion has been up for awhile. Synchronizing your code is a trade off of performance vs. consistency or security if you will. What code needs synchronization is solely up to the designer.
You may be interested in perusing the following two maestros of concurrent programming:
Paul Hyde
Doug Lea
Both are very fundamental helping you create intuitive understanding of threads.
 
Consider Paul's rocket mass heater.
reply
    Bookmark Topic Watch Topic
  • New Topic