Newbie thread stuff

L

Luc The Perverse

In reviewing my post, I have realized that I included a lot of superfluous
information. To allow you to quickly find the most condensed version of my
question I will put it between two rows of asterisks.

Well I've gone from only having done one program in Java with general
contempt for the language a few months ago, to absolutely loving the
language. I've done over a hundred algorithm implementations in Java at
Topcoder improving both my understanding of the semantics of the language
and my algorithm solving skills (which may or may not be algorithm
independent).

I have made a working VERY rudimentary java program which works like this.
1. It starts a thread to begin collecting names of media files.
2. It loads up a Form from which you can search

public static void main(String[] args) {
final FileList theList = new FileList();
BackgroundListPopulator mysearch = new
BackgroundListPopulator("d:\\My Music", theList); //Note: change hard
coded path to be compiler line option
mysearch.start();

javax.swing.SwingUtilities.invokeLater(new Runnable() {
public void run() {
createAndShowGUI(theList);
}
});

I generate a FileList object which the compiler told me had to be final
to be used in the inline class. BackgroundListPopulator is my Thread
derived class which searches for all files and puts them into a giant linked
list. It sets a boolean in theList object to signal when it has completed.

The code after that is cut and pasted from a GUI tutorial on the Sun
website. While I understand in theory what the invokeLater function does -
I do not see why I need to do this - it seems to complicate matters. I am
pretty sure I have made GUIs before without this :"protection"

There is a lot that I don't like about this. First - it seems like it
should be easier to get data to the search form. Creating a final in this
instance works - but that is not always going to be the case.

********** The question *********
My mutex is just a boolean. Right now if the boolean is false when the
search button is clicked, I simply display "not ready" in the JList box. I
would like to use true mutex and have the search display as soon as the
results are available - but I know I cannot block in the UI thread. What is
a good way to go about this?
*********************************

I decided to give eclipse and netbeans a try - but netbeans quickly
stole my heart as I was able to quickly draw a beautiful form - which is all
I really want an IDE for anyway. Compared with the ridiculously ugly GUI
my first draft program had, this was a notable improvement. I need to read
up and google some more - I don't know how to reference a public class found
in another file. I thought you could just call it by name, but NetBeans got
mad when I tried to draw the form I had just made. I will figure that out
though.

Just a side note: Search results are virtually instantaneous. The
start time even for a first instance of the JVM is less than the amount of
time that the windows dog dances for. I compiled my code in a trial version
of excelsior and I was able to get my start time down to near a second (not
actually measured, just watching)
 
R

Robert Klemme

Luc said:
I have made a working VERY rudimentary java program which works like this.
1. It starts a thread to begin collecting names of media files.
2. It loads up a Form from which you can search
********** The question *********
My mutex is just a boolean. Right now if the boolean is false when the
search button is clicked, I simply display "not ready" in the JList box. I
would like to use true mutex and have the search display as soon as the
results are available - but I know I cannot block in the UI thread. What is
a good way to go about this?
*********************************

You'll have to do it event style. Just put another call to
invokeLater() into the code when the task is finished. That call then
will notify the UI elements of the finished task. As easy as that - and
you don't need additional synchronization yourself and you don't need
that flag (a simple boolean isn't really a mutex).

Kind regards

robert
 
C

Chris Uppal

Luc said:
The code after that is cut and pasted from a GUI tutorial on the Sun
website. While I understand in theory what the invokeLater function does
- I do not see why I need to do this - it seems to complicate matters.
I am pretty sure I have made GUIs before without this :"protection"

Probably the best way to think of it is that Sun are unable to get the
threading bugs out of AWT, so they have (now) decided that it's best to execute
/all/ AWT-related code in the EDT. Sometimes (often!) Swing initialisation
works without invokeLater(), sometimes it doesn't. Better safe than sorry...

There is a lot that I don't like about this. First - it seems like it
should be easier to get data to the search form. Creating a final in
this instance works - but that is not always going to be the case.

You might find it easier and/or more esthetically pleasing, if you add the
items incrementally as they are discovered (or perhaps in batches). Add them
to your JList's ListModel (see getModel()) or your JTable's TableModel
(getModel() again). You'll need to use invokeLater() if the code doing the
adding isn't runniing on the EDT.

You may find that the ListModel/TableModel replaces your current FileList, or
conversely, that it's a good idea to make FileList function as a
ListModel/TableModel.

-- chris
 
R

Rogan Dawes

Luc said:
********** The question *********
My mutex is just a boolean. Right now if the boolean is false when the
search button is clicked, I simply display "not ready" in the JList box. I
would like to use true mutex and have the search display as soon as the
results are available - but I know I cannot block in the UI thread. What is
a good way to go about this?
*********************************

Take a look at SwingWorker. It is intended for long-running tasks
spawned from the Swing EDT (Event Dispatching Thread), where the results
need to be given back to a Swing component.


Here is an example taken from
<http://java.sun.com/docs/books/tutorial/uiswing/misc/threads.html>

final SwingWorker worker = new SwingWorker() {
ImageIcon icon = null;

public Object construct() {
icon = new ImageIcon(getURL(imagePath));
return icon; //return value not used by this program
}

//Runs on the event-dispatching thread.
public void finished() {
Photo pic = (Photo)pictures.elementAt(index);
pic.setIcon(icon);
if (index == current)
updatePhotograph(index, pic);
}
};
worker.start();

This would typically be executed in an event handler, or could be
executed as part of the constructor of your UI, once your UI objects
have been created.

finished() is called on the EDT only AFTER construct() has exited.

You might also want to take a look at JProgressBar
Hope this helps.

Rogan
 
T

Thomas Hawtin

Luc said:
The code after that is cut and pasted from a GUI tutorial on the Sun
website. While I understand in theory what the invokeLater function does -
I do not see why I need to do this - it seems to complicate matters. I am
pretty sure I have made GUIs before without this :"protection"

They may work, but can you be sure they always work? What about on a
different Java implementation? Both when moving to 1.5 and to 1.6 I
uncovered a deadlock in jEdit. The only safe thing to do is to program
like the JVM is out to get you, because it probably is.

Tom Hawtin
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,484
Members
44,903
Latest member
orderPeak8CBDGummies

Latest Threads

Top