Try to enjoy your work while doing it,it will Automatically convert in Hard Work...
Try to enjoy your work while doing it,it will Automatically convert in Hard Work...
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.praveen kumaar wrote: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.
Try to enjoy your work while doing it,it will Automatically convert in Hard Work...
Ganesh Patekar wrote:And I hope you know what wait, notifyAll and Thread.sleep methods do...
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.
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.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 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.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.
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;
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?
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?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.
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.
We begin by testing your absorbancy by exposing you to this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|