The loader threads access Swing components directly. They should be scheduling tasks on the AWT event thread. This might explain some of the stability issues others have been seeing.
Can you tell me where you think this is happening? Both the Set/Photo Retriever Threads call .setCountText and .addImageDiaplayPanel (which are methods of ImageDisplayContainer). Those two methods do the actual setText and add in a SwingUtilities.invokeLater call.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The Swing component access starts even in the main thread when FlickrBackupGUI is created. Later, the photo retriever thread retrieves the photo identifiers from Flickr and then iterates through each of them to create image panels. The addImageDisplayPanel method is implemented to use invokeLater, but the PhotoDisplayPanel argument is constructed in the retriever thread. The PhotoDisplayPanel creates and manipulates numerous Swing objects when it is constructed. That Swing/AWT access is happening on the photo retriever thread (I've verified this in a debugger).
I think the implementation of the multithreaded code may have other problems as well. For example,
public void setCountText(String countText) {
this.mCountText = countText;
SwingUtilities.invokeLater(new Runnable() {
public void run() {
mCountLabel.setText(mCountText);
}
});
}
The mCountText field is being set in a retriever thread and then read in the AWT thread. Without synchronization or declaring the field volatile, there is no guarantee that the two threads will see the same value on a multiprocessor/core computer. I've only scanned the code quickly, but it appears that there may be many of these types of multithreading issues that could lead to unstable behavior of the GUI on multicore boxes. Brian Goetz's book, "Java Concurrency in Practice" is a great resource to learn more about this topic.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for your detail! The reason I create the Photo/SetDisplayPanel in the thread is because it takes a long time. It goes out to flickr and downloads the thumbnail, etc. So when I put that in the event thread, it locks up the GUI. Also, those components aren't visible until I add them (not sure if that really matters...). If you have any time to give me some code, that would be great. Thanks again for the help!
I hadn't thought about the multicore issue, but I'm developing and running on a multicore processor and I don't see issues, but I under stand what you are saying there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=338394
Originator: NO
Can you tell me where you think this is happening? Both the Set/Photo Retriever Threads call .setCountText and .addImageDiaplayPanel (which are methods of ImageDisplayContainer). Those two methods do the actual setText and add in a SwingUtilities.invokeLater call.
Logged In: YES
user_id=362035
Originator: YES
The Swing component access starts even in the main thread when FlickrBackupGUI is created. Later, the photo retriever thread retrieves the photo identifiers from Flickr and then iterates through each of them to create image panels. The addImageDisplayPanel method is implemented to use invokeLater, but the PhotoDisplayPanel argument is constructed in the retriever thread. The PhotoDisplayPanel creates and manipulates numerous Swing objects when it is constructed. That Swing/AWT access is happening on the photo retriever thread (I've verified this in a debugger).
I think the implementation of the multithreaded code may have other problems as well. For example,
public void setCountText(String countText) {
this.mCountText = countText;
SwingUtilities.invokeLater(new Runnable() {
public void run() {
mCountLabel.setText(mCountText);
}
});
}
The mCountText field is being set in a retriever thread and then read in the AWT thread. Without synchronization or declaring the field volatile, there is no guarantee that the two threads will see the same value on a multiprocessor/core computer. I've only scanned the code quickly, but it appears that there may be many of these types of multithreading issues that could lead to unstable behavior of the GUI on multicore boxes. Brian Goetz's book, "Java Concurrency in Practice" is a great resource to learn more about this topic.
Logged In: YES
user_id=338394
Originator: NO
Thanks for your detail! The reason I create the Photo/SetDisplayPanel in the thread is because it takes a long time. It goes out to flickr and downloads the thumbnail, etc. So when I put that in the event thread, it locks up the GUI. Also, those components aren't visible until I add them (not sure if that really matters...). If you have any time to give me some code, that would be great. Thanks again for the help!
I hadn't thought about the multicore issue, but I'm developing and running on a multicore processor and I don't see issues, but I under stand what you are saying there.