wood burning stoves 2.0*
The moose likes Threads and Synchronization and the fly likes Doubts about synchronization - I suppose it is a simple question Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Java » Threads and Synchronization
Bookmark "Doubts about synchronization - I suppose it is a simple question" Watch "Doubts about synchronization - I suppose it is a simple question" New topic
Author

Doubts about synchronization - I suppose it is a simple question

Josh Borg
Ranch Hand

Joined: Oct 02, 2012
Posts: 32

Following the code:



I want to know whats the purpose of wait(p) in the first class? If I synchronize 'p' instance why I need to synchronize the object in the second class with the "synchronized(this){}". I want to know also if there is probability of notify in the second class occurs before the "p.wait()" instruction in the first class.
Thanks.
Jelle Klap
Bartender

Joined: Mar 10, 2008
Posts: 1778
    
    7

The purpose of the synchronized(this) block in the Prodotor2 class can be found in the documentation of Object.notify():
JavaDoc wrote:
This method should only be called by a thread that is the owner of this object's monitor. A thread becomes the owner of the object's monitor in one of three ways:
  • By executing a synchronized instance method of that object.
  • By executing the body of a synchronized statement that synchronizes on the object.
  • For objects of type Class, by executing a synchronized static method of that class.


  • If you remove the synchronized block an IllegalMonitorStateException will be thrown when you notify is called, as per the documentation.

    As for your second question: yes.
    Though in this specific case, you'll likely never encouter the problem in practice. Still, the program is fundametally flawed in that regard. The consumer should call wait() from within a loop, and that loop should check the wait condition: is there anything to consume yet? In your example that could be a simple (volatile) boolean flag that Produtor2 sets when it's finished its loop.

    By the way, it's better to implement Runnable than to extend Thread, because you're creating logic to be executed by a Thread, rather than an extension of Thread; something that IS-A Thread. Not hugely important in this example, but something worth getting in the habit of nonetheless, especially considering single inheritance.

    Build a man a fire, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life.
    Raul Cosio
    Greenhorn

    Joined: Aug 16, 2012
    Posts: 6
    There is a better approach to the producer-consumer pattern:



    Note that:
    - The consumer is inside a daemon Thread, so it will be automatically finished when your program finishes.
    - There is a lockWait object used to guarantee that the Thread is completely started, otherwise your program could end before doing anything.
    - The queue instance is used to communicate both threads.
    - The Thread.sleep() gives the daemon Thread some time to finish, otherwise your program could end before all numbers are consumed. Maybe you would want to create a non-daemon Thread and include logic to stop it at the end of your program.
     
    Consider Paul's rocket mass heater.
     
    subject: Doubts about synchronization - I suppose it is a simple question