• Post Reply Bookmark Topic Watch Topic
  • New Topic

Thread problem please help  RSS feed

 
Chaveen Ekanayake
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi guys.

I have a problem with notifing objects. I know a object can not be notified for a perticular thread using Object.wait();. Is there any classes or methodes that can wake up a perticular thread in waiting pool?
[ August 21, 2008: Message edited by: Chaveen Ekanayake ]
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you maintain references to the threads, you could call thread.interrupt() which will break the wait() but will also cause an exception. If you want the thread to come out of waiting in normal flow, you have to use the notify.

Do you have multiple threads waiting on the same object? Why do you want to wake one particular thread? There may be other, better solutions to your problem.
 
Chaveen Ekanayake
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
ya I have multiple threads waiting on one monitor. If I use notify() or notifyAll() a randomly selected thread will gain the monitor. But I don't want that. I want the thread which I want to run to be executed. Do you guys have any solutions.
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Why do you want one particular thread to run, rather than a random one? How do you decide which one should run?

You may consider using a ReentrantLock with a Condition for each thread (or group of related threads). This would replace the synchronized/wait/notify system.

Alternatively, each of your runnables could have a trigger that sets wether, when notified, they should do their work, or should continue waiting:


Any runnables that have not been triggered to run will go back to waiting, while only the one that was told it was ready will be able to go.
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I think ReentrantLock with multiple conditions is the way to go but if for some reasons you can not do it, then you can use this class:



So in the sync blocks in waiting threads:



In the sync blocks in notifying threads:


Steve,

Waiking up a thread just to find out that it was a wrong notification is probably something that will not be that recommendable.
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Nitesh Kant:
Steve,

Waiking up a thread just to find out that it was a wrong notification is probably something that will not be that recommendable.


Actually it is consistent and suggested in the Object#wait() API documents. So I would think it is recommendable.
 
Chaveen Ekanayake
Greenhorn
Posts: 17
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
hi. thanks for the posts guys. But I can't understand why that's not recommended?? please explain me
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Chaveen Ekanayake:
hi. thanks for the posts guys. But I can't understand why that's not recommended?? please explain me


The Lock/Condition paradigm would be preferred because it is more expressive and flexible than the wait/notify system. It is a very robust system that allows you control multiple release conditions for objects waiting on a single Lock, without any dependency between waiter and notifier. If your system has the java.util.concurrent package (java 5+) you should use the ReentrantLock/Condition system.

The monitor method that Nitesh provided is a good approximation of the Lock/Condition paradigm. With the actual code provided you are limited to 1 notifier to 1 waiter. By modifying it some you can change it to many : many, but I am not convinced you could get the same control you get from the Lock/Condition approach. There is a weak link between the waiter and notifier (the id to get the monitor), but there isn't any type dependency.

The boolean alternative is a simple to understand and simple to implement alternative. It can give you the same granularity as Lock/Condition with some more work (if you build a small notifier framework you can simplify the process). As I said in my previous post, I don't think this approach should be avoided, as the API specifically suggests to code against aberrant notifies. The worst part about this approach is the need to hold references to the runners performing the work, which creates a type dependency which you don't need with the other approaches (again, a framework could reduce this).
 
Ajay Saxena
Ranch Hand
Posts: 154
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
The problem is to notify a particular thread from a group of threads waiting on the SAME monitor.

So how does maintaining thread specific monitors help in this case?
 
Steve Luke
Bartender
Posts: 4181
22
IntelliJ IDE Java Python
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Originally posted by Ajay Saxena:
The problem is to notify a particular thread from a group of threads waiting on the SAME monitor.

So how does maintaining thread specific monitors help in this case?


No, the solution the OP asked for is to notify a particular thread from a group of threads waiting on the same monitor. We don't actually know the problem. We only know what the question is. We did ask the OP for more details but he hasn't answered.

But not knowing the real problem, the solution might be anything, including a call-back system, or any of the previously mentioned solutions.
[ August 24, 2008: Message edited by: Steve Luke ]
 
Nitesh Kant
Bartender
Posts: 1638
IntelliJ IDE Java MySQL Database
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Steve:
Actually it is consistent and suggested in the Object#wait() API documents. So I would think it is recommendable.


Well the API actually talks about spurious wakeups which are rare. In this case though, if the number of threads increase, then it will proportionately increase the cpu cycles wastage(including the context switch overhead to get a thread back into the running state).
So, I *think* it will be better to notify only the thread that is supposed to be notified rather than notifying all, out of which, only one will eventually work and all else will go back to wait.

Ajay:
The problem is to notify a particular thread from a group of threads waiting on the SAME monitor.

So how does maintaining thread specific monitors help in this case?


If more than one threads are waiting on the same monitor then waking up exactly one thread without using conditions is not possible.
That is the reason why i suggested that each thread should wait on a different monitor.(Needless to mention that this is not for guarding a code against multiple threads access but to use a notification scheme between threads.)
I think I should have mentioned this in my post to avoid confusions.

Steve:
The monitor method that Nitesh provided is a good approximation of the Lock/Condition paradigm. With the actual code provided you are limited to 1 notifier to 1 waiter. By modifying it some you can change it to many : many, but I am not convinced you could get the same control you get from the Lock/Condition approach. There is a weak link between the waiter and notifier (the id to get the monitor), but there isn't any type dependency.


Agree, that code is not really a replacement for the lock-condition thing.
However, it can be used in certain specific situations where the whole intention is to notify specific threads. I thought that this was what the OP required i.e. to be able to notify a single thread.
BTW, a backport of the concurrent library is available here
[ August 25, 2008: Message edited by: Nitesh Kant ]
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!