• Post Reply Bookmark Topic Watch Topic
  • New Topic

Help with threads  RSS feed

 
Chris Beltin
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I am trying to write a program to practice with threads but am having trouble getting to grips with wait and notify.
I have a buffer that stores objects and a number of threads (workers) that continuously remove items from this buffer. A single thread controls these threads and is supposed to suspend them one at a time if the number of objects in the buffer is too low and resume them if there are too many.
The way I have approached it is to put a wait() in the run() method of the worker thread. The wait is enclosed in an if statement that is executed if a boolean variable is true. The controlling thread monitors the number of objects in the buffer and changes the boolean value of a worker if it wants to suspend it so that the worker calls wait on itself on the next iteration.
Could someone let me know if this seems correct?
The problem that I have then got is that I am unsure where to put the call to notify() in order to resume them (one at a time).
Should the controller call notify on the worker through a method in the worker class?
Thanks in advance.
Chris
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Hi Chris,
Welcome to JavaRanch!
First, I have to ask you to read the JavaRanch naming policy, which requires that your display name include a complete, non-fictitious-sounding first and last name. If you'd head over here and change it, I'd appreciate it. Thanks, pardner!
OK, now. Sounds like you've got the basic idea down correctly. I need to tell you two things. First, never write "if (flag) wait()". Always write "while (flag) wait()". It is possible that wait() will return and the flag will still be false. This can happen if, for example, notify() is called multiple times in succession. Your programs will be much safer if you follow this simple rule.
Second, the important thing is that wait() and notify() need to be called on the same object for the communication to occur. Also remember that if you call wait() without calling it on an object, you're calling it on the current object -- the object whose method is running.
In general, if two threads need to communicate using wait() and notify(), they need to agree on what object they'll use. The way this is commonly done in your situation is to give the queue class methods like this (simplified, and the removeElementAt(0) is inefficient, but you get the idea)



Then threads can just call addToQueue() and getFromQueue() without worrying about synchronization at all. The Queue object itself is the one that wait() and notify() will be called on (and called by). If a thread calls getFromQueue() and there are no items to get, it will just wait() for one to appear.
Make sense?
 
Chris Beltin
Greenhorn
Posts: 3
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Ok, sorted the name thing. Damn greenhorns eh?
What you've said has reinforced what I've already done in my queue class so I now know I've approached that correctly and understand why it works.
The problem I am trying to overcome is that I want to dynamically suspend and resume threads based purely on a comparison between the size of the queue and the number of currently active threads.
The queue will constantly be having items added from elsewhere and the workers will constantly be taking them out.
The single contolling thread that monitors the workers is not really concerned with whether there are items in the queue to be removed (this is done by the queue as you described). It just needs to suspend them if there are too few items (since they are being removed faster than they are replaced) or re-activate them if there are not enough (vice vesa).
I'm not sure if this is explained clear enough, its quite difficult to write down but basically the queue restricts calls from workers using wait and notify but a controller thread suspends them (possibly indefinately) in an effort to stabilise the number of active threads with the size of the queue.
 
Ernest Friedman-Hill
author and iconoclast
Sheriff
Posts: 24217
38
Chrome Eclipse IDE Mac OS X
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
I'd still try to write this using a "pull" model, so that getFromQueue() would look something like (I'm realizing now that, here and in the above, I'm forgetting those pesky InterruptedException handlers!)

And then in the worker thread class, something like
 
Stan James
(instanceof Sidekick)
Ranch Hand
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
If you're not averse to peeking at the answers, look into the Jakarta Commons Thread Pool. It includes a queue that is just what you're talking about here.
 
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!