Runaway Thread
Hi,
Ok, so multi-tjreading is the word. I implement the following:
publicvoid inits()
{
try
{
initAll();// GUI inits
dtartThreads();// threads that need to run
}
}
When I run this JAppjet ... nothing. Far be it from breaking down open doors (and answering my own questions) but am I right in assuming the following:
- the inits take longer thus the actual initting takes place in a separate Thread() hence the threads already take over the CPU and the inits take far longer;
- Thread() start should begin after a timed delay;
- when a Thread() runs, does it have to be suspended to receive parameters or for a methog to be invoked?
when this:
Thread t;
Thing c:// of course inplementing Runnable...
c =new Thing(eDta);
y =new Thread(c):
t.start;
then, later in time:
t.doScanList();
do I have tostop/suspend the Thread() t for a few moments to evecute the methog and then restart is?
All of this to avoid a mess-over of my code to come to the answers - the hard way - and see that I was wrong (as often..._grin_)
Tnx in advance
Thor
[1567 byte] By [
T01deva] at [2007-11-27 11:31:01]
# 1
Weird formulated question :/
Yes the initialisation of a thread takes some time (from a machine-cycles point of view it takes ages). AFAIK if you start a thread control is moved in most cases to the newly created Thread, but this is all depending on xx factors (like does your machine have 32 CPUs instead of just 1, is the OS you're running on MAC-OS, LINUX, WINDOWS or ..., are you running the applet using jre1.1.8 or jre1.6 or something in between). Important here is that you would like the inits method to end before the threads and all of their contexts are created.
public void inits() {
DelayedThreadStarter starter = new DelayedThreadStarter();
new Thread(starter).start();
initAll(); // gui stuff
starter.wakeUp();
}
static class DelayedThreadStarter implements Runnable {
public synchronized void wakeUp() {
this.notifyAll();
}
@Override
public void run() {
// wait for 1000 ms (1 second) or a signal from the main thread before continuing
final long TIME_TO_WAIT = 1000;
synchronized(this) {
long start = System.currentTimeMillis();
while(true) {
long dif = System.currentTimeMillis()-start;
if (dif>=TIME_TO_WAIT) {
break;
}
try {
this.wait(TIME_TO_WAIT-dif);
// notify wass called .. so we break loop
break;
} catch (InterruptedException ignore) {
// something interrupted the thread (it was not notified .. so we continue the waiting)
}
}
}
// at this point we either got signaled or otherwise a period of TIME_TO_WAIT has passed
startThreads();
}
}
Here's a start ... you could even add a lower priority to the DelayedStarterThread before starting it.
the thingie about the doScanList() I don't understand and therefor can not answer that question.
Regards,
Douwe Vos
# 2
Hmm, just as I expected : the Thread() takes ages and the GUI has no more chance to "squeeze" in and the appjet seems to have "hung up the phone"...
A delayed startup (as you have shown) seems in order.
The second bit (the update...) is simply during the execution of the Thread(). It would be some form of watcher that has to watch a few more classes during exec. It would be initialised, would have its list of stuff to look for fed to it and started off. Then, during the whole run, the watcher could heve to watch something more...how that is done I know (I'd feed it an ID - no puzzle here) but can the watcher keep running or do I have to "suspend" it while I feed the ID to it...
# 3
If you realy want a fast loaded applet (i.e. your own loader that is telling the user that the applet is starting) then you might consider using reflection or create your own classloader (I have not details on a classloaders in combination with an applet or if it is possible to use your own (with all the security constraints on applets :S ))
About the second part.. Still don't understand much :( .. but here is as how I see it: you have a thread observing a list of objects and this list might be changed by another thread. Some questions arise here:
1: How is the thread monitoring the objects in the list. Is it just iterating over the items over and over again (lets say pulling for changes). Or are those threads that are modifying the objects in this list notifying the monitoring thread (lets say push). If you've choosen the first then I could advise you: "please don't unless its absolutely necessary "
2: what type of list are you using: does the javadoc tell you that it is a thread safe list ?
3. while iterating over the list do you somehow lock the list for modifications or do you make a (thread safe/atomic) copy of the list first.
# 4
Hi,
Sorry about the delayed reply...just got of a weekend shift... ;-)
Well, the second bit is a bit tricky, let me illustrate using some (bogus) code:
At first there is the construct of the object that is to run in its own Thread:
(at first)
// set us some Classes, to be added to an ArrayList in the Class th
CarrierClass a = new CarrierClass([some variables]);
// more of the same...
(then, the void to set things up)
...
Thing th, // the Class to hold the carriers
Thread t; // no comment - we Java devzz know what this thing is ;-)
// ok, set out the "chalk marks here
th = new Thing();
th.register(a); // "give the thing th a CarrierClass type of object
// repeat this for the other previously set CarriecClasses
// and set the thing running
t = new Thread(th);
t.start; // of course
(in the course od the proceedings, along comes annother CarrierClass, to be added to the
// already running th - running happily in its Thread()
CarrierClass c = new CarrierClass([more variables]);
// and now...here's what I suspect will [b]not[/b] work:
[code]th.regiter(c);
(ect)
Donty I need to at least suspend th for a while, like so:
th.suspend();
th.register(c);
th.resume();
As far as the run-aways go, I can happily follow your (wise) suggestion : to delay the kick-off for Threads until such time the GUI is ready and presentable, after all, what good is a running Thread() if the user cannot interact with it (via the GUI - that is)?
Thanks for spending some time on this puzzle...but not too much, is IS weeken after all(grin)
Thor
