*
The moose likes Beginning Java and the fly likes Wake up a thread Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Android Security Essentials Live Lessons this week in the Android forum!
JavaRanch » Java Forums » Java » Beginning Java
Bookmark "Wake up a thread" Watch "Wake up a thread" New topic
Author

Wake up a thread

Aleksey Vladimirovich
Ranch Hand

Joined: Sep 05, 2012
Posts: 56
Hi guys! Could you please tell me if there are any other possible ways to wake up a thread besides calling notify() or notifyAll() on it? I need my thread to wait and then be awoken by calling my own method... Is it possible?
Aleksey Vladimirovich
Ranch Hand

Joined: Sep 05, 2012
Posts: 56
Anyone?
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4167
    
  21

The short answer is there are dozens of ways of making one thread wait for another thread. The question is, why doesn't wait()/notify() work for you? Knowing that will help determine which is the best route to take.


Steve
Aleksey Vladimirovich
Ranch Hand

Joined: Sep 05, 2012
Posts: 56
Steve Luke wrote:The short answer is there are dozens of ways of making one thread wait for another thread. The question is, why doesn't wait()/notify() work for you? Knowing that will help determine which is the best route to take.

No-no, wait() is okay, the thing is to wake a thread with my own method (not notify()). I'll explain why I need it: I've created a class ImageDownloader, which has to work then and only then when it has objects waiting for images to be downloaded, here is an example:

Please ignore the Vector collection (I know it's not good), unfortunately I have to deal with old java 1.4 here
So I want my loader to wake up by triggering addListener() method. Is it possible?
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4167
    
  21

Aleksey Vladimirovich wrote:No-no, wait() is okay, the thing is to wake a thread with my own method (not notify()).

You can't wake from a wait() without a notify(), so if you don't want to use notify() you can't use wait().



I don't see any reason why wait()/notify() wouldn't work in this scenario. You generally shouldn't wait()/notify() on a Thread objects, but you shouldn't be extending Thread anyway; rather implement Runnable, and pass an instance into a Thread.

If you worry that your producer doesn't have access to the instance of this ImageDownloader, you would create an arbitrary Object, pass it to both the downloaded and all the producers, and synchronize on that:

Then the producers would use the same Object and do:


Of course, a Lock and Condition (java.util.concurrent.lock package) could do the same sort of thing.

Your code follows a normal 'Producer - Consumer' situation where the thread you show is the consumer. The best approach in this case is to use a BlockingQueue to hold the images that need to be downloaded. Whoever generates the images put()s them in the BlockingQueue, while the consumer here take()s them out. When there is nothing to take out, the consumer would be blocking on the take() method. This is usually coupled with a PoisonPill - a special object you put in the BlockingQueue to get the consumer to stop blocking and realize that the work is done and it should shut down.
Steve Luke
Bartender

Joined: Jan 28, 2003
Posts: 4167
    
  21

Aleksey Vladimirovich wrote:Please ignore the Vector collection (I know it's not good), unfortunately I have to deal with old java 1.4 here

Vector was bad in Java 1.4 - much better tools where available then, so this is not a good excuse for using Vector.

It is, however, a good reason not to use the Lock/Condition and the BlockingQueue stuff I mentioned in my last post. There is a backport of that stuff available (from sourceforge) that you can provide as a library to your code, or you could see about upgrading to a modern version of Java (I recommend this but understand it isn't always possible), or you should figure out the wait()/notify() thing.
Aleksey Vladimirovich
Ranch Hand

Joined: Sep 05, 2012
Posts: 56
Thank you, Steve for such a good explanation, I appreciate it
Vector was bad in Java 1.4 - much better tools where available then, so this is not a good excuse for using Vector.

I still haven't figured out what tools were you talking about. I want to get rid of synchronized collections like Vector and Hashtable so badly, but I can't find any alternatives in java me (yeah, that's probably a detail I should have mentioned in the beginning of the post, sorry) Anyways, if it's possible, please give me some tips
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14074
    
  16

ArrayList and HashMap instead of Vector and Hashtable.

But since you didn't mention until now that you're working on Java ME, Steve ofcourse didn't know that you can't use those because they're not there in the library for Java ME.


Java Beginners FAQ - JavaRanch SCJP FAQ - The Java Tutorial - Java SE 7 API documentation
Scala Notes - My blog about Scala
Aleksey Vladimirovich
Ranch Hand

Joined: Sep 05, 2012
Posts: 56
Jesper de Jong wrote:ArrayList and HashMap instead of Vector and Hashtable.

But since you didn't mention until now that you're working on Java ME, Steve ofcourse didn't know that you can't use those because they're not there in the library for Java ME.

Yea, I'm aware of these collections and it's a shame that they're not available in J2ME, I just thought maybe there were any alternatives of ones in J2ME.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7549
    
  18

Aleksey Vladimirovich wrote:Yea, I'm aware of these collections and it's a shame that they're not available in J2ME, I just thought maybe there were any alternatives of ones in J2ME.

But Vector and Hashtable are? That would suggest to me that J2ME is many versions behind Java SE, which strikes me as a problem right there.

I wonder also if threading isn't a red herring here. If you want something notified of a change, my suggestion would be to implement the Observable/Observer pattern. Then you can implement any kind of notification you want.

Winston


Isn't it funny how there's always time and money enough to do it WRONG?
Articles by Winston can be found here
Jesper de Jong
Java Cowboy
Saloon Keeper

Joined: Aug 16, 2005
Posts: 14074
    
  16

Winston Gutkowski wrote:But Vector and Hashtable are? That would suggest to me that J2ME is many versions behind Java SE, which strikes me as a problem right there.

Java ME indeed has a very limited subset of the standard Java API - you can find the API documentation here. A year ago or so at Devoxx (November 2011) I remember Oracle promising that there would be a newer and updated version of Java ME in the future, but it seems that it's not yet there.
Aleksey Vladimirovich
Ranch Hand

Joined: Sep 05, 2012
Posts: 56
Winston Gutkowski wrote:
But Vector and Hashtable are? That would suggest to me that J2ME is many versions behind Java SE, which strikes me as a problem right there.

I wonder also if threading isn't a red herring here. If you want something notified of a change, my suggestion would be to implement the Observable/Observer pattern. Then you can implement any kind of notification you want.

Well, it is far behind J2SE and it sucks J2ME is very primitive and in addition to that it is not open source. Sorry, I'm not sure what "red herring" mean, but if you meant "excessive" than the answer is no, I wanted to implement lazy image downloader and there is no way to do it without threading. And yes, I've used the Observer pattern here, it works fine, but I'm still worring about memory overhead...I guess there is nothing I can do here though.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7549
    
  18

Aleksey Vladimirovich wrote:...but if you meant "excessive" than the answer is no, I wanted to implement lazy image downloader and there is no way to do it without threading. And yes, I've used the Observer pattern here, it works fine...

Then I'm not quite sure what your question is. The Thread is the thing that needs to do the notification, so just register it with your Observable (presumably your cache of images) and notify it that it's complete.

but I'm still worring about memory overhead...I guess there is nothing I can do here though.

What overhead? The image itself is likely to be far bigger than anything else you need to concern yourself with.

But, as I say, maybe I'm just being thick and don't follow what your problem is.

Winston
Aleksey Vladimirovich
Ranch Hand

Joined: Sep 05, 2012
Posts: 56
Winston Gutkowski wrote:Then I'm not quite sure what your question is. The Thread is the thing that needs to do the notification, so just register it with your Observable (presumably your cache of images) and notify it that it's complete.

The problem is in absense of experience in java Now it works fine - once the image is downloaded the thread tells another object to redraw graphics of a widget, everything seems to work smoothly.
Winston Gutkowski wrote:What overhead? The image itself is likely to be far bigger than anything else you need to concern yourself with.
But, as I say, maybe I'm just being thick and don't follow what your problem is.

Sorry, maybe my posts were a bit misleading...I'm concerned about the collections not only in this particular piece of code, but all over my app, it has to process pretty big amounts of data (at least as for mobile device) and I have to use these old collections on and on since I don't have alternatives. As for images - they are sort of small logos (about 2K each) and there is nothing to do with them...I mean as a programmer I cannot save memory on them, unlike these inefficient collections, but I guess I just have to accept it.
Winston Gutkowski
Bartender

Joined: Mar 17, 2011
Posts: 7549
    
  18

Aleksey Vladimirovich wrote:As for images - they are sort of small logos (about 2K each) and there is nothing to do with them...I mean as a programmer I cannot save memory on them, unlike these inefficient collections, but I guess I just have to accept it.

Well, for starters, those collections are only time inefficient, because they're synchronized when there's often no need. I doubt whether there's very much difference (if any) in space efficiency between them and the newer types. The basic overhead is for the collection object itself (maybe 20-30 bytes) and a dozen or so for each element because it must be an object. Hashtables will also have an overhead for the internal bucket store; however, since each of your objects is already 2K it's likely to be a drop in the ocean.

HIH

Winston
Aleksey Vladimirovich
Ranch Hand

Joined: Sep 05, 2012
Posts: 56
Winston Gutkowski wrote:
Aleksey Vladimirovich wrote:As for images - they are sort of small logos (about 2K each) and there is nothing to do with them...I mean as a programmer I cannot save memory on them, unlike these inefficient collections, but I guess I just have to accept it.

Well, for starters, those collections are only time inefficient, because they're synchronized when there's often no need. I doubt whether there's very much difference (if any) in space efficiency between them and the newer types. The basic overhead is for the collection object itself (maybe 20-30 bytes) and a dozen or so for each element because it must be an object. Hashtables will also have an overhead for the internal bucket store; however, since each of your objects is already 2K it's likely to be a drop in the ocean.

HIH

Winston


Yea, I'm aware that they are time inefficient because of being synchronized, but for some reason I thought, in addition to that they consume large amounts of memory, you just opened my eyes. The collections are still bothering me, but at least I've learnt something new, thank you
 
It is sorta covered in the JavaRanch Style Guide.
 
subject: Wake up a thread
 
Similar Threads
Customize 'Save As' dialog box provided by browser at client side
groovy and javafx
Tidying up my code?
SCEA Part 2 - Basic Questions
Greetings!