I am trying to refresh my java thread knowledge. I came across a question about how to create a sample example showing inter thread communication. I have found that we can use wait() and notify() for this purpose. Now for the sake for creating a sample example, I want to threads to communicate with each other using wait() and notify(). The sequence is like this: Thread A will run, it will call Thread B and go into wait state.
Now Thread B will run, it will call Thread A and go into wait state..
I tried to convert this logic into code, but was unable to make it work that way. I will try to recreate the code at home, but I just wanted to know if this is possible using two threads, or do I have to create a third thread and make Thread A and Thread B extend it?
I know there are many example, but I want to understand the logic without going for the shortcut step.. Please point some direction..
I just wanted to know if this is possible using two threads,
It depends what you mean. Your description is rather vague, and terms like "calling a thread" are not really standard.
or do I have to create a third thread and make Thread A and Thread B extend it?
I don't know what you mean by "extend" here, but if you're talking about the class hierarchy keyword "extends", then, no, you definitely don't need to do that here, and you should really never extend Thread in practice.
I am not getting time to re-create the code, I will do it by tomorrow for sure. and regarding the Thread calls, the point was that , can we show inter thread communication using wait() and notify() using two thread classes, or do we need to add some other layers in between them to manage their communication..
okay, this is the code, it is an outline, but it won't work. I know that.. logically also it has issues.
the other class :
Now, the sequence which i wanted to see is this: Operator1 will run, it will call and notify Operator2 and go into wait() state. Now Operator2 will have some delay, it will notify Operator1 and go into wait() state. This is really looking like chicken and egg problem. where to start itself is confusing..
1. Don't extend Thread. Implement Runnable. (I'm pretty sure I already told you this.) You're not creating a specialized Thread class; you're just defining a task to be run in a separate thread.
2. If you did extend Thread, overriding start() as you did makes no sense.
3. I already told you, you don't need two separate classes. Just one is fine. Your classes look identical, unless I missed something, so why would you need two of them?
4. Both classes have main methods. That suggests you're going to be starting two separate JVMs. Interthread communication only works within a single JVM.
5. Even if you put both of these into a single JVM, you're syncing on two different objects, so neither thread can ever block the other, and neither notify() call can ever affect the other thread.
6. And finally, I still don't know what you mean by "call and notify Operator2". However, if you literally mean just using notify()/notifyAll(), then you have a problem. For x.notify() to do anything some other thread has to already have called x.wait(). You can't in general assume that thread T1 will get to the point of calling wait() before T2 gets to the point of calling notify() without some other control. One way to do it would be to have a share boolean variable seen by both threads.
I'll ask this for the last time: What are you really trying to accomplish here? If you say anything about "one thread calling or notifying another" then you're just repeating what's already not clear, and that doesn't make it any clearer.
Have you gone through some multithreading tutorials or books? Worked the exercises? Changed them around to see how that affects the behavior and make sure you really understand it?
Or did you just glance at one or two things, get a rough idea of what methods are involved and are now just randomly throwing code at the wall to see what sticks?
You need to start at the very beginning of a concurrency book or tutorial, and go through it slowly and carefully. There are too many fundamental concepts that you clearly have no idea about yet.
thanks for reply. sorry about the unclear objective.. like i said above, it is a basic layout of what i was thinking.. i already know the logic is almost weirdly.. i always think of trying to run two seperate programs for inter communication.. bad habits from working on some other applications i guess..
about the extending of Thread, this is just an example, if i can get it working... tht is all what is required. this is not for my project..
about the two different objects, i was thinking of creating singleton objects and using it in the opposite class and starting both from a single main... well i will try to apply your suggestions, and will come back..
s ravi chandran wrote:
i always think of trying to run two seperate programs for inter communication.. bad habits from working on some other applications i guess..
No, not a bad habit. Inter-process communication happens all the time. It is neither better nor worse than inter-thread communication. But if you are specifically interested in inter-thread communication in Java, then, of necessity and by definition, it must be a single process.
about the two different objects, i was thinking of creating singleton objects and using it in the opposite class and starting both from a single main.
Why would you want two Singletons when the two classes are identical?
Jeff Verdegan wrote:you don't need two separate classes
Can you please clarify it? What I understand from it is that producer-consumer problem can be simulated using only 1 class. Is it so? Because almost all examples talk about two classes : producer and consumer. Consumer waits and producer notifies.
Jeff Verdegan wrote:you don't need two separate classes
Can you please clarify it?
I don't know what's to clarify. You can do it with a single class. That should have been obvious when he had two singletons that were identical. Why would anybody do that instead of just creating two instances of one single class?
What I understand from it is that producer-consumer problem can be simulated using only 1 class. Is it so?
Well, yes, one could implement producer/consumer with a single class. However, that would be a horrible design.
And, more to the point, that's not at all what I was talking about
1) Nobody ever mentioned producer/consumer up until you did just now.
2) The above code looks nothing like a producer/consumer implementation.
3) So when I said "you can do it with one class," why would you think I was talking about producer/consumer? I was talking about what he said in his first post: "create a sample example showing inter thread communication". You're the one who assumed producer/consumer from that.