Wake up a thread

[Aleksey Vladimirovich]

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]

Anyone?

[Steve Luke]

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.

[Aleksey Vladimirovich]

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:

    
public class ImageDownloader extends Thread {
        
        private Vector listeners = new Vector();
        boolean quit = false;
        
        public void addListener(IImageDownloadListener listener) {
            listeners.addElement(listener);
        }
        
        public void run() {
            while (!quit) {
                for (int i = 0; i < listeners.size(); ++i) {
                    //downloading image for each IImageDownloadListener object
                }
                synchronized (this) {
                    try {
                        wait();
                    } catch (InterruptedException e) {
                        System.out.println("*****ImageLoader: failed attempting to put thread on sleep*****");
                        e.printStackTrace();
                    }
                }
            }
        }
        
        public void interrupt() {
            quit = true;
        }
        
    }

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]

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().

    
public class ImageDownloader extends Thread {
        
        private Vector listeners = new Vector();
        boolean quit = false;
        
        public void addListener(IImageDownloadListener listener) {
            listeners.addElement(listener);
        }
        
        public void run() {
            while (!quit) {
                for (int i = 0; i < listeners.size(); ++i) {
                    //downloading image for each IImageDownloadListener object
                }
                synchronized (this) {
                    try {
                        wait();
                    } catch (InterruptedException e) {
                        System.out.println("*****ImageLoader: failed attempting to put thread on sleep*****");
                        e.printStackTrace();
                    }
                }
            }
        }
        
        public void interrupt() {
            quit = true;
        }
        
    }

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:

public class ImageDownloader implements Runnable
{
    //...
    private final Object synchronizer;

    public ImageDownloader(Object toSynchronizeOn)
    {
        this.synchronizer = toSynchronizeOn;
        //...
    }

    //...
            synchronized(this.synchronizer)
            {
                this.synchronizer.wait();
             }
    //...

Then the producers would use the same Object and do:

            synchronized(this.synchronizer)
            {
                this.synchronizer.notify();
            }

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]

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]

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]

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.

[Aleksey Vladimirovich]

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]

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

[Jesper de Jong]

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]

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]

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]

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]

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]

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