I'm having some troubles pausing and resuming a method. (Using Java in Eclipse).
Basically I'm writing a program that works a bit like a compiler. I give it a string and it interprets this string, converts it in a block of n commands,conditions and things like loops (depending on the strong) and executes those commands. Like so:
(while
(energy-at-least 1000)
(seq
(move)
(turn clockwise)
)
)
Currently I have a method that stops at the Nth command, but I'm unsure of how to continue after this, since reusing this method and telling it to start at the Nth+1 command mmakes it forget that the program is in loop(s).
Sorry for the poor explanation, but basically I need to be able to stop this method at the Nth command and let it resume from the course it was following. Java had methods for these (resume() and stop() ) but they are deprecated I've seen. Anybody have a good idea?
From what I understand your saying is that you need more fine grained control over the loop in the thread then methods like 'notify', 'resume', etc. are offering. You can do such a thing like this:
The class of the thread could look like this:
public WhateverLoop implements Runnable {
private volatile boolean run = true;
public void run() {
while(run) {
doWhatever();
}
}
public setRun(boolean run) {
this.run = run;
}
}
The 'volatile' part is very important. It enables other threads to influence the 'run' variable (basically it prevents threads copying it into their own memory). Otherwise changes from other threads to the variable won't be visible in the thread.
The controlling class could do this:
WhateverLoop whateverLoop = new WhateverLoop();
Thread WhateverLoopThread = new Thread(whateverLoop);
whateverLoopThread.start();
// Do stuff which consumes time.
...
// Stop the loop
whateverLoop.setRun(false);
In this example I used a boolean, but obviously you can make it as complicated as you want (or not).
An easy way to do this would be to use wait() and notify() methods. Of course, it will depend on how many parallel threads you'll have running since the notify() method cannot guarantee you which thread will actually be awaken.
One way to do this is to represent the execution state in such a way that the subset that is required to resume can be stored in heap objects reachable from a "context" object.
To pause execution, you get the interpretter to record all relevant state in a context object, and return it. To resume, you call the interpretter passing in the previously used context.
This won't work if your interpretter does a recursive walk of the program tree to execute it ...
Another way to do this is to implement "pause" by having the interpretter execute a callback to your CLI (or whatever it is that handles stuff while the program is paused). The CLI "resumes" execution by returning from the callback method.
Have you considered controlling it from a BlockingQueue?
Start it with a queue of N instructions for it to execute. It will pull each instruction from the queue and process it. Once it reaches the Nth instruction it will stop/block. To start it again from where it left off, push more instructions into the queue.
Related
I have the following piece of code:
public static void main(String[] args) {
...
while(condition.continueListening()) {
}
log.info("Finished");
}
The condition object creates its own thread that after one condition is met, make the method continueListening, to return false.
The thing is that, I want the main thread to not to finish until that method returns false, and the way I implemented it, it's by using this structure that it's quite "hard" for the CPU, do you know any other approach that could work better?
What is continueListening checking? If its just a random piece of state, you don't really have a good choice, best you can do is make your thread sleep for a little bit, say a half second in the while loop.
But if you can change continueListening, then you can have it block until an event happens and it should continue. Java has many options for this, some could be:
You could wait for the other thread to exit using Thread.join().
Wait for the thread to notify on some object that it has done something (similar idea to join but the thread can carry on and do something else). Object.wait(), Object.notify().
Use the Java "executor", this is similar to waiting for a thread to exit, but has built in means to transfer results and errors, and allows Java to use things like thread pools. See ExecutorService and Future.get()
Various other waitable event objects or queues. Such as doing something manually with Future and Promise, or BlockingQueue.
I have the following situation. I have an application that runs mostly on one thread. It has grown large, so I would like to run a watchdog thread that gets called whenever the main thread changes into a different block of code / method / class so I can see there is "movement" in the code. If the watchdog gets called by the same area for more than a second or a few, it shall set a volatile boolean that the main thread reads at the next checkpoint and terminate / restart.
Now the problem is getting either of the threads to run somewhat at the same time. As soon as the main thread is running, it will not let the watchdog timer count properly. I was therefore thinking of yielding every time it calls the watchdog (so it could calculate time passed and set the value) but to no avail. Using Thread.sleep(1) instead of Thread.yield() works. But I don't want to have several areas of code just wasting calculation time, I am sure I am not doing it the way it is meant to be used.
Here a very simple example of how I would use Thread.yield(). I do not understand why the Threads here will not switch (they do, after a "long" and largely unpredictable time). Please give me an advice on how to make this simple example output ONE and TWO after each other. Like written before, if I switch yield() with sleep(1), it will work just like I'd need it to (in spite of waiting senselessly).
Runnable run1 = new Runnable(){
public void run(){
while(true){
System.out.println("ONE");
Thread.yield();
}
}
};
Runnable run2 = new Runnable(){
public void run(){
while(true){
System.out.println("TWO");
Thread.yield();
}
}
};
Thread tr1 = new Thread(run1);
Thread tr2 = new Thread(run2);
tr1.start();
tr2.start();
Thread.yield()
This static method is essentially used to notify the system that the
current thread is willing to "give up the CPU" for a while. The
general idea is that:
The thread scheduler will select a different thread to run instead of
the current one.
However, the details of how yielding is implemented by the thread
scheduler differ from platform to platform. In general, you shouldn't
rely on it behaving in a particular way. Things that differ include:
when, after yielding, the thread will get an opportunity to run again;
whether or not the thread foregoes its remaining quantum.
The take away is this behavior is pretty much optional and not guaranteed to actually do anything deterministically.
What you are trying to do is serialize the output of two threads in your example and synchronize the output in your stated problem ( which is a different problem ), and that will require some sort of lock or mutex to block the second thread until the first thread is done, which kind of defeats the point of concurrency which is usually the reason threads are used.
Solution
What you really want is a shared piece of data for a flag status that the second thread can react to the first thread changing. Preferably and event driven message passing pattern would be even easier to implement in a concurrently safe manner.
The second thread would be spawned by the first thread and a method called on it to increment the counter for which block it is in, you would just use pure message passing and pass in a state flag Enum or some other notification of a state change.
What you don't want to do is do any kind of polling. Make it event driven and just have the second thread running always and checking the state of its instance variable that gets set by the parent thread.
I do not understand why the Threads here will not switch (they do, after a "long" and largely unpredictable time). Please give me an advice on how to make this simple example output ONE and TWO after each other. Like written before, if I switch yield() with sleep(1), it will work just like I'd need it to (in spite of waiting senselessly).
I think this is more about the difference between ~1000 println calls in a second (when you use sleep(1)) and many, many more without the sleep. I think the Thread is actually yielding but it may be that it is on a multiple processor box so the yield is effectively a no-op.
So what you are seeing is purely a race condition high volume blast to System.out. If you ran this for a minute with the results going to a file I think you'd see a similar number of "ONE" and "TWO" messages in the output. Even if you removed the yield() you would see this behavior.
I just ran a quick trial with your code sending the output to /tmp/x. The program with yield() ran for 5 seconds, generated 1.9m/483k lines, with the output sort | uniq -c of:
243152 ONE
240409 TWO
This means that each thread is generating upwards of 40,000 lines/second. Then I removed the yield() statements and I got just about the same results with different counts of lines like you'd expect with the race conditions -- but the same order of magnitude.
I have a program where I compile java code a user types into a text field, and then run it. A run the code in a seperate thread, so that the GUI they use to input the source code doesn't get locked up.
The GUI has an abort button that should stop the thread. My issue is that I need to stop the compiling thread no matter what is going on inside of it, which means I must account for a case where the thread is caught in an infinite loop (due to user error), and it cannot properly end itself using a safe flag. I've read up on many solutions that involve using a flag of some kind, but they aren't available to me because of this looping issue. I need to have the thread stop and the memory it's using freed (I can't just let it sit in the background forever, unless that is the only solution left). Any advice or alternative solutions? Hopefully some fresh perspectives could help squash this issue.
Edit:
Here's a sample bit of user submitted code:
public class RunMe extends SomethingThatRuns {
public void run() {
int i = 0;
while (i = 0) {
//Prepare to get stuck!
}
}
}
I'll compile this class, and then run it. This is where it will get stuck, and the run() method can never finish, or even loop to check a flag.
You can run it in a new JVM so you can kill it when you want.
Thinking about security this may be a good thing to do too.
Call stop() on the thread.
Yes, this is a deprecated method. However, it really shouldn't be "deprecated", it should be "dangerous." In some circumstances, however, there's really no choice but to use it, and the invocation of an "agent" provided by a user is one of those cases.
Make sure that your program doesn't use any data that are manipulated by this user thread; or, if you do, devise some transactional mechanism to exchange data safely between the threads.
Even this method isn't guaranteed to terminate the thread. For example, the user can catch the resulting Throwable and ignore it. Or, the thread implementation might not respond to stop() calls if the thread is in some native code. But it's your best chance.
The core issue here is the fact that the code even allows an infinite loop to be entered as part of user error. Fix that, and everything else will become easier to deal with.
Properly-behaving threads should usually terminate themselves gracefully when there's no work to do (or return quietly to a thread pool to ask for more work, if that's your application's design). If you feel like you need to have one thread forcefully kill another then you've likely got a fundamental design issue. It's fine to have one thread tell another, "Hey, you should terminate now so that I can join with you..." because that allows your threads to clean things up as they finish. Forcefully destroying threads just isn't the right way to manage these situations.
You can use them to insert a interrputed check in every loop and maybe in other places too.
I can see two options:
As you compile the user code you can edit it before. You may use
ANTLR to parse and modify the code.
There are bytecode manipulation frameworks like ASM that allow you to manipulate code that is already
compiled.
I don't think it is easy but it might be a way.
interupt(); the Thread in the gui
and in the code that the thread runs regularly check for Thread.interrupted() and throw an exception when you do especially inside loops
At a high level, you are asking how one thread might go about stopping another thread. To that end, see this SO question Stopping a Thread in Java?.
i have to write a "WatchDog" in Java, who secure that Threads don't perform too long. With the initialization of the Objects it's no Problem, i made a Class, who calls the WatchDog and the constructor with reflections in the run() method.
A Thread is easy to stop, but how i can secure normal methods of objects?
For example i call the method of an Object and this method perform a endless loop, how you would do that?
thanks
First, I should point out that stopping a thread is NOT easy. In fact, in the general case, threads cannot be stopped safely:
You can call Thread.interrupt() on a thread the you want to stop, but there is no guarantee that the thread will notice the interrupt, let alone actually stop.
You can call the deprecated Thread.stop() method, but this method is unsafe. If you call it at an unfortunate moment, you can leave data structures in a half-updated state, leave other threads waiting (for ever) on signals that won't arrive and so on.
Here's how I'd implement a watchdog for method execution.
First I'd modify the method to add two calls to the watchdog service; e.g.
public void someMethod(...) {
Watchdog.startMethod(maxTime);
// do stuff
Watchdog.endMethod();
}
Next, I'd implement the Watchdog with a priority queue ordered on expiry time:
The startMethod(maxTime) would add an entry to the queue with expiry time of now + maxTime. The entry would include a reference to the current thread (when the method was called.
The endMethod() would look for a (the) queue entry for the current thread, and remove it if found.
The watchdog thread would periodically look at the first queue entry. If that entry had an expiry less than 'now', the watchdog would remove the entry, stop its thread and check the next entry. Repeat until the next entry hasn't expired.
Some thought would need to be given to the data structures, and to dealing with cases where endMethod calls get skipped. (Indeed, since a method call can terminate due to an exception, the endMethod() call really needs to be done in a finally block.)
Note that the startMethod and endMethod calls could (and maybe should) be inserted by an annotation processor or something like that.
Given the complexity, and the fact that you can't guarantee to stop the thread (safely), I'd think of some solution that doesn't involve a method watchdog.
Normal methods of objects are running on some thread. It might be the AWT event dispatcher or whatever it's called. Or it might be the main thread, say, of a console application.
They are no different to the threads that are called with new Thread().
I guess your watchdog needs to be looking at all the threads in the VM and looking for ones which have a utilisation >= some threshold.
What code do you have so far?
Rich
Try to use #Timeable annotation from jcabi-aspects:
public class Resource {
#Timeable(limit = 5, unit = TimeUnit.SECONDS)
public String load(URL url) {
return url.openConnection().getContent();
}
}
Your method will be interrupted on timeout.
So this is really complicated, it took me a while to realize what's actually happening. Hopefully you understand it better than me though.
I have a Swing class that displays the GUI. In the GUI i have a button, and in the Swing class i have a method that is called whenever i click the button.
When that method is called, i call another method in an object called "Manager". The method in manager then calls another method in a class called "Core". That method in Core sets a local variable, and then calls another method in Core, that self-invokes itself.
The problem is that since it's self-invocing, it never stops running, right? And since it never stops running, nothing is ever returned to the first method in Core. And since nothing is returned to that method, nothing is returned to Manager either. And since that method is never called, the GUI class never gets a response, which leaves the GUI frozen.
Horribly sorry for the messy description. I can't post the code unfortunately. I hope anyone gets my point though, someone must have had the same issue before.
Thanks!
EDIT:
I forgot to mention that the Core class is a thread.
Your long-running process is preventing the main Swing thread, the EDT or event dispatch thread, from continuing, and this will make your GUI completely unresponsive. The solution is to do any long-running process in a background thread such as created by a SwingWorker object. Please check out the link called Concurrency in Swing to learn more about use of SwingWorker objects.
Self-invocation is called recursion. It's a powerful technique, but could lead to infinite loops (hanging) if you're not careful. You need to make sure every recursion (i.e. every time the method invokes itself) something changes towards a terminating state. For example, you could have a number that is guaranteed to decrease every recursion and have as exit condition that your number is negative. Another example is that you're recursively "eating up" some data structure, let's say a string, until there's nothing left. Usually this "something that changes towards a terminating state" is passed to the method as an argument. Your recursive method should start with a check: is my argument in a terminating state? If yes, terminate, if no, do magic.
Secondly, with Swing you should be careful not to violate it's architecture. It's not really MVC, but rather a 2-layered framework. If you're interested in how to use Swing, I recommend reading up on design patterns like MVC.
You got a number of problems.
1) Your recursive function needs an exit condition. So something like
public int imRecursive(int arg) {
if (arg > 100) return;
imRecursive(arg++);
}
in that example, imRecursive doesn't get called over and over, it stops once arg reaches 100.
2) With a swing app, only GUI related code should run in the main event-dispatching thread. If your recursive method is long running, you should use a SwingWorker to do it in another thread so your GUI doesn't lock up.
Post some code. You say Core is a Thread, I assume that means class Core extends Thread but we need to see where you are spawning a new thread (calling a method in a class that extends Thread does not make it run in a separate thread).
Your recursive (self-invoking) method, if it never breaks the recursion, will before too long cause StackOverflowError. If you are not getting that then either you are not using a recursive function or breaking the recursion somewhere. The right way to code a method that never terminates is not recursion, it is iteration.
The GUI freezing is almost certainly because some time-consuming processing is occurring in the GUI thread, one more reason to believe that the method in Core is not running in a separate thread.
I don't understand WHY you have to self-invoke your method...
are you trying to do some recursion?
if the method never ends, you got a infinite loop, its not good.
Depending for what you are trying, you may use Java Threads, or, rethink your code.. i bet you're doing something wrong.
You need to analyse your self-invoking method call - This is a recursive call - but every recursive method must have some condition that stops the recursion - check under what conditions in your case you should get such a condition