• Post Reply Bookmark Topic Watch Topic
  • New Topic

Thread

 
praveen kumaar
Ranch Hand
Posts: 444
22
Android Chrome Eclipse IDE Google App Engine Java Notepad Oracle Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
i am going through a "Thread" section of java docs(tutorial) here i do not understand the role of variable named "empty" and also the use of loop(when does it go in a loop).

please help me.
 
Campbell Ritchie
Marshal
Posts: 52615
119
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If the empty field is in a producer class for a producer‑consumer example, it means the producer is empty, i.e. it has no products ready to supply to the consumer.
 
praveen kumaar
Ranch Hand
Posts: 444
22
Android Chrome Eclipse IDE Google App Engine Java Notepad Oracle Ubuntu Windows
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
actually i understand that thing its like a box where consumer retrieve the items inside a box unless it is empty and also the producer will deliver the item inside the box when it gets empty
i.e,producer cannot fill during retreiving process and consumer cannot retrieve during a delivery process..
am i right?

now what i need to ask is suppose producer thread is undergoing.their we use the same Drop object for both threads,empty is initially true,when inside a producer thread it calls a put method initially it will not go through loop as empty is true and also sets empty to false now when consumer retrieve their again empty is false so it willl not gothrough loop so how does it make sense to use the loop here in the way it does.
 
Ganesh Patekar
Bartender
Posts: 696
23
Eclipse IDE Hibernate Java jQuery MySQL Database Netbeans IDE Oracle Spring Tomcat Server
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
praveen kumaar wrote:producer cannot fill during retreiving process and consumer cannot retrieve during a delivery process..
am i right?
Yes correct, this is one of the two kinds of thread synchronizations which Java's monotor supports called as Cooperation, which is supported in the Java virtual machine via the wait and notify methods of class Object, enables threads to work together towards a common goal. Here their common goal is one will write(Producer) and other will read(Consumer) but not simultaneously.
now what i need to ask is suppose producer thread is undergoing.their we use the same Drop object for both threads,empty is initially true,when inside a producer thread it calls a put method initially it will not go through loop as empty is true and also sets empty to false now when consumer retrieve their again empty is false so it willl not gothrough loop so how does it make sense to use the loop here in the way it does.


  • Just to understand general concept, assume there is a message box which can have message in It which is put by producer and read Or retrieve Or consume by consumer.
  • Producer thread puts message in message box only If It is empty else wait for consumer to read It and consumer thread retrieves message from message box only If It is not empty else wait for producer to put message in It. If message box is not empty then consumer retrives It and after retrieving that message consumer thread makes message box empty by assigning empty = true so producer thread can put another message in It.
  • All this information of whether message box is empty Or not is communicated via variable empty of boolean type.
  • According to the value of empty variable these producer and consumer threads perform wait OR notifyAll to communicate with each other as I mentioned above about cooperation synchronization.
  • Producer will call wait() only when message box is already full means It will wait for consumer thread to perform action.
  • How producers knows message box is empty Or not, as mentioned above using boolean variable empty. If empty = true then write message else wait for consumer to retrieve message.
  • If message box is empty then producer thread will execute this below part of put method because at this moment value of empty is true so will not go in while(!empty){...} loop but in below code.
  • If message box is not empty means producer has already put message in message box at this moment value of empty is false and then producer thread will execute this below part of put method and will wait for consumer thread to read that message and make It empty so producer can again put message in it by executing above code in code tag.


  • Same logic consumer thread uses to execute code in take method.
  • When message box is empty means empty = true then consumer executes below code and wait for producer to put message in message box.
  • When message box is not empty means empty = false then consumer executes below code and retrives message and makes message box empty by assigning empty = true so producer can put message in message box again by checking value of empty i.e. true which tells producer that consumer has already read message.

  • This way value of empty plays important role in invoking either wait Or notifyAll methods of Object class.

  •  
    Ganesh Patekar
    Bartender
    Posts: 696
    23
    Eclipse IDE Hibernate Java jQuery MySQL Database Netbeans IDE Oracle Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    And I hope you know what wait, notifyAll and Thread.sleep methods do...
     
    praveen kumaar
    Ranch Hand
    Posts: 444
    22
    Android Chrome Eclipse IDE Google App Engine Java Notepad Oracle Ubuntu Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    thanks for the support ganesh,nice explanation.
     
    Ganesh Patekar
    Bartender
    Posts: 696
    23
    Eclipse IDE Hibernate Java jQuery MySQL Database Netbeans IDE Oracle Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    You're welcome
     
    Henry Wong
    author
    Sheriff
    Posts: 22542
    109
    C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Ganesh Patekar wrote:And I hope you know what wait, notifyAll and Thread.sleep methods do...

    And since this was mentioned...

    Ganesh Patekar wrote:
  • When message box is not empty means empty = false then consumer executes below code and retrives message and makes message box empty by assigning empty = true so producer can put message in message box again by checking value of empty i.e. true which tells producer that consumer has already read message.



  • Interestingly, if there is exactly one producer and one consumer, then notifyAll() is not needed. A notify() call, which only notifies one waiting thread, works fine. This is needed, in case there are multiple producers and consumers.

    However, if there are multiple producers and consumers, then the comment is wrong. This code doesn't just notify the producer that status has changed -- it notifies all waiting threads, which includes all the producers (and other consumers too) that the status has change. This is clearly an inefficient thing to do -- and unfortunately, can't be helped due to a flaw in the design. A notification assumes that any waking thread can handle it, which isn't true if a consumer wakes up another consumer.


    Anyway to fix this, it is probably better to port this to use the ReentrantLock class, and to use two Condition instances (one for the producers and one for the consumers). This way, you can efficiently just make a signal() call to wake up one thread, instead of all the threads.

    Henry
     
    Ganesh Patekar
    Bartender
    Posts: 696
    23
    Eclipse IDE Hibernate Java jQuery MySQL Database Netbeans IDE Oracle Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Henry Wong wrote:Interestingly, if there is exactly one producer and one consumer, then notifyAll() is not needed. A notify() call, which only notifies one waiting thread, works fine. This is needed, in case there are multiple producers and consumers.
    Yes here I considered only one producer and one consumer thread. I knew about that notify() method notifies only one waiting thread and notifyAll() notifies all waiting threads but didn't know why I unnoticed that, notifyAll() is not needed. Thank you so much for pointing It.

    However, if there are multiple producers and consumers, then the comment is wrong. This code doesn't just notify the producer that status has changed -- it notifies all waiting threads, which includes all the producers (and other consumers too) that the status has change. This is clearly an inefficient thing to do -- and unfortunately, can't be helped due to a flaw in the design. A notification assumes that any waking thread can handle it, which isn't true if a consumer wakes up another consumer. 
    Yes I got about this. About high-level concurrency features which was introduced in 5.0 I'm yet to read about It but will sure read It.

    What so far I understood is
  • Every object has an associated monitor.
  • Every object has an associated wait set. Wait set is a set of threads waiting to acquire monitor. When an object is first created, It's wait set is empty .
  • I hope this object in given example means the object referred by demo reference variable. So this object referred by demo will have a monitor and a wait set.
  • Hope I'm on correct path please correct me If I'm wrong.

    A thread will be in wait set only when It calls wait method am I correct?
  • Now when notifyAll() is called only by thread currently owning monitor then all threads including producer and consumer from wait set will compete with each other to acquire the monitor.

  • Here is the main problem what I didn't inderstand
  • When notify() is called only by thread currently owning the monitor although there are more than one thread in wait set then only one particular chosen thread will be awakened that thread will acquire the monitor but Here notify() method says

  • public final void notify() wrote: If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation. The awakened thread will compete in the usual manner with any other threads that might be actively competing to synchronize on this object;

    How could other threads in wait set will be competing with chosen thread to acquire monitor If notifyAll() is not called. Aren't they suppose to not compete to acquire monitor unless and untill indicated by current thread owning monitor by invoking notifyAll() method?
     
    Henry Wong
    author
    Sheriff
    Posts: 22542
    109
    C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Ganesh Patekar wrote:
    Here is the main problem what I didn't inderstand
  • When notify() is called only by thread currently owning the monitor although there are more than one thread in wait set then only one particular chosen thread will be awakened that thread will acquire the monitor but Here notify() method says

  • public final void notify() wrote: If any threads are waiting on this object, one of them is chosen to be awakened. The choice is arbitrary and occurs at the discretion of the implementation. The awakened thread will compete in the usual manner with any other threads that might be actively competing to synchronize on this object;

    How could other threads in wait set will be competing with chosen thread to acquire monitor If notifyAll() is not called. Aren't they suppose to not compete to acquire monitor unless and untill indicated by current thread owning monitor by invoking notifyAll() method?


    The notify() method wakes up one thread. The notifyAll() method wakes up all the threads. Okay, this part is clear.

    However, keep in mind that, whether you wake up one waiting thread or all the waiting threads, the waking thread(s) do not have the synchronization lock, and must compete for it ... well, if you only notified one thread ... then who is this thread competing with, you may ask?

    Well, one possibility is the notifying thread. Perhaps, after making the notify() or notifyAll() call, it has other stuff to do, and maintains ownership of the lock. Until the lock is released, the waking thread is blocked.

    Or another possibility is a thread that didn't call the wait() method. For example, a consumer gets a task (and goes off to do the task). Since the thread is busy working, it didn't call wait. So, later when it comes back, it needs to grab the lock first, but the lock is owned by the notifying thread. The notification is sent (and the lock is released), then the waking thread has to then compete with the thread returning from the task. Whoever gets it first gets a task to work on -- and the other has to return back to a wait state.

    Henry
     
    Ganesh Patekar
    Bartender
    Posts: 696
    23
    Eclipse IDE Hibernate Java jQuery MySQL Database Netbeans IDE Oracle Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    Henry Wong wrote:another possibility is a thread that didn't call the wait() method. For example, a consumer gets a task (and goes off to do the task). Since the thread is busy working, it didn't call wait. So, later when it comes back, it needs to grab the lock first, but the lock is owned the notifying thread. The notification is sent, the waking thread has to then compete with the thread returning from the task. Whoever gets it first gets a task to work on -- and the other has to return back to a wait state.
    Ohh yes, there could be a thread which is not in wait set but will compete with chosen thread. I read here --->Thread Synchronization by Bill Venners so will that thread which was not in wait set be in entry set as that article mentions?

    Here It just beneath the Figure 20-1 A Java Monitor mentions
    Thread Synchronization by Bill Venners wrote:
    When a thread arrives at the start of a monitor region, it enters the monitor via the leftmost door, door number one, and finds itself in the rectangle that houses the entry set. If no thread currently owns the monitor and no other threads are waiting in the entry set, the thread passes immediately through the next door, door number two, and becomes the owner of the monitor. As the monitor owner, the thread continues executing the monitor region. If, on the other hand, there is another thread currently claiming ownership of the monitor, the newly arrived thread must wait in the entry set, possibly along with other threads already waiting there. The newly arrived thread is blocked and therefore doesn't execute any further into the monitor region.
     
    Henry Wong
    author
    Sheriff
    Posts: 22542
    109
    C++ Chrome Eclipse IDE Firefox Browser Java jQuery Linux VI Editor Windows
    • Likes 1
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator

    Well, I don't know if the analogy / drawing (which you have not shown) works as well, but I guess.

    Both the thread that is entering synchronization, and the thread that has been awoken by notification, are blocked on acquiring the lock. The only differences are that (1) the waking thread is technically already "in the house" code wise, and just need to reacquire the lock to return from the wait() method.

    And (2) the waking thread may actually acquire the synchronization lock more than once. For example, if the thread that called wait(), had acquire the lock five times, and released it (in order to wait for notification), it needs to reacquire that lock five times again. It needs to return from the wait() method with the same lock count that it was called with.

    Henry
     
    Ganesh Patekar
    Bartender
    Posts: 696
    23
    Eclipse IDE Hibernate Java jQuery MySQL Database Netbeans IDE Oracle Spring Tomcat Server
    • Mark post as helpful
    • send pies
    • Quote
    • Report post to moderator
    This is the figure from that artical which I was talking about. Yes got that now. Thank you so much     Image Source
    Java-Monitor.png
    [Thumbnail for Java-Monitor.png]
     
    • Post Reply Bookmark Topic Watch Topic
    • New Topic
    Boost this thread!