• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Doubts about synchronization - I suppose it is a simple question

 
Josh Borg
Ranch Hand
Posts: 35
Chrome Eclipse IDE Netbeans IDE
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 1951
7
Eclipse IDE Java
  • 0
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
     
    Raul Cosio
    Greenhorn
    Posts: 6
    • 0
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    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.
     
    It is sorta covered in the JavaRanch Style Guide.
    • Post Reply
    • Bookmark Topic Watch Topic
    • New Topic