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.
Related
I have a controller thread that is permanently in synchronized(lock): It does a calculation step, then it does wait(1000), then it checks if more work is to be done. If so, it does another step and waits(1000). If not, it just waits(1000) straightaway. (Mind that I'm using wait, not sleep.)
Sometimes, the calculation steps called by the controller ask the controller to call them many times in a row - that's a high performance mode lasting for multiple seconds. During this time, no other thread (e.g. Swing) could alter data used by this controller thread. Swing would now hang if it tried to do this!
I want to keep the balance between high performance and good fluidity.
Therefore, I want to add wait(1) in this high performance mode loop.
QUESTION: Will a thread waiting to grab the lock achieve dominance with ABSOLUTE certainty, if I sprinkle these wait(1) calls into the calculation loop?
QUESTION: Will a thread waiting to grab the lock achieve dominance with ABSOLUTE certainty, if I sprinkle these wait(1) calls into the calculation loop?
The short answer is sort of in that you are always getting the lock when lock.wait(1) returns. However, I don't think you understand how to use lock and notify to gain control over a shared resource. To call lock.wait(1) you need to own the lock to start with.
The call releases the lock and returns either if lock.notify() or notifyAll() was called or if the timeout expires and (NOTE) the lock is available to be locked again. This means that if someone else owns the lock for a long period of time, the wait(...) method won't return unless the lock is released – which could be for many milliseconds. It is designed to help threads coordinate between themselves.
If the question is "does calling wait(1) in a calculation loop only give the lock to other people for 1ms" then the answer is no.
If you have a resource that can only be used by one thread at a time then the other threads will need to wait until it is available. You hope that each thread uses the resource for a short amount of time so the waiting is small.
You can protect the resource using a couple of different mechanisms. The easiest is to just put a synchronized block around its use. This protects it from race conditions and ensures that any changes to the resource gets published to main memory in all threads. No wait or notify calls are required using this mechanism.
Another way of doing it is to use lock.wait(...) and lock.notify(). This mechanism is required when (for example) threads are consuming from a collection and need to wait for there to be entities added. In this case, when a thread adds an entity to the collection it calls lock.notify() and any thread(s) waiting for work in lock.wait() will be notified that there is work to do and will awaken.
The use of the lock.wait(...) timeout argument means that threads can wait for a certain amount of time for the resource to be available before giving up. In the queue processing example above, the threads may need to check if the application is shutting down every second or so. So they call lock.wait(1000), test if the shutdown flag has been set, and if not they can check for work to be done and then call wait again. Just because you are calling lock.wait(1) doesn't ensure any sort of lock "dominance" and doesn't mean that the method returns after 1ms.
If you want to use wait and notify signaling then you would need a secondary variable to check to see if the resource is in use. The following example uses an inUse boolean field.
private final Object lock = new Object();
private boolean inUse = false;
...
synchronized (lock) {
while (inUse) {
lock.wait();
}
inUse = true;
}
// use the resource
...
synchronized (lock) {
inUse = false;
lock.notify();
}
Notice that the example tests for inUse in a while loop and not just an if. This is an important pattern and is needed because you could be notified but another thread might have gotten access to the resource while you were waiting.
Say that blockAndDoSomeLongWork() is a method that blocks. Usually, we'd perform it on another thread:
someExecutorService.execute(() -> {
blockAndDoSomeLongWork();
});
Question is: is there a way to notify a thread that i've called blockAndDoSomeLongWork() after the fact so that i will be absolutely sure that the other thread won't do anything before blockAndDoSomeLongWork() has been called? If i simply wake up the other thread via call in the lambda's body that immediately precedes blockAndDoSomeLongWork(), this makes it possible for the other thread to execute an action before blockAndDoSomeLongWork() was called, which is something i want to avoid.
Use a semaphore:
Semaphore sema = new Semaphore(0);
This thread:
someExecutorService.execute(() -> {
blockAndDoSomeLongWork();
sema.release();
});
Other thread:
sema.acquire();
// when we get here, the 'long work' has completed
This assumes there is exactly one 'other' thread, and rather more subtly, assumes that the 'long work' is a one-time thing. Otherwise you might need two-way interlocking.
No, this is impossible. It's hard to imagine why you would ever need it.
Let's say there was a notifyOtherThreadAndBlock() call.
This call would notify the other thread and then block.
But, this call has code in it. It notifies the other thread, then it blocks. What if your thread gets stopped after the notifying, and before the blocking? This is the same problem you already had. Putting it into a function didn't solve anything.
Now, it is theoretically possible. Maybe the operating system could have a function that says "hey, next time I block, please notify this other thread for me." But operating systems don't have that function. Why not? Because it's useless. You're supposed to just notify the other thread before you start blocking, because it doesn't make any difference anyway.
If it does make a difference, then your code is doing something wrong, and you should explain your situation better, so we can explain how to make it so you can notify before blocking.
Thread class has many static methods that are called by class name. Some of them are:
But yet, we are provided with method currentThread() that returns currently executing thread object. Some are:
Unfortunately, this created confusion in my head. When I think of a method I want, I have no clue whether I would found it as static or instance. So why did they make such two approaches?
I mean, couldn't they all be grouped in same 'calling'? For example why is sleep() static and not instance method called with Thread.currentThread().sleep()? Another weird example is between interrupted() and isInterrupted() defined in different manner. They do exactly the same thing, just interrupted() additionally clears interrupted flag. Has anyone logic answer to this, so I have no struggle where to find each method?
It's tricky; the answer is different for each method. Let's go through the ones you named:
Thread.sleep
Imagine I called: someOtherThread.sleep(1000L);. What would this mean? Surely that ought to mean: Sleep that other thread, not my thread. Except that's not something java offers: You can sleep your own thread, but you cannot arbitrarily tell some other thread to freeze like they're doing a mime act, mid execution of some arbitrary command. For example, if that thread is currently blocked on, say, waiting for the OS to deliver some bytes from a file read, that definitely cannot just fall asleep, and there are many, many other scenarios where a thread cannot do that.
Thus, java does not offer this functionality - you can't sleep other threads. Only your own. There are two different ways to make this at least somewhat clear in API design:
The first is to have sleep be an instance method (thus, you'd have to write e.g. Thread.currentThread().sleep(1000L);), and spec the method that it will guaranteed, always, immediately throw an IllegalStateException if you invoke it on any thread except your own. This means a compile/write-time detectable error condition would only be caught at runtime (this is bad; catching a problem earlier is obviously better than catching it later), it makes the code you'd have to write to sleep needlessly longer, and the existence of a sleep method you can invoke on thread instances sure suggests that you can sleep other threads. It'd just be crappy API design.
The second is to make sleep static.
Think of it this way: java.lang.Thread is a container for two mostly unrelated batches of methods: One is a set of methods you can use on threads (those'd be the instance methods). The other is a bunch of thread and flow related primitives, such as 'sleep', 'yield', and interrupt interaction. They just happen to be shoved into the same class.
interrupt
This is probably the trickiest. Unlike sleeping, you can in fact ask another thread's interrupt flag status.
The reason there are two methods are because of the more or less intended API design of the interrupt system.
The interrupt system is designed as follows:
If you want some thread to stop what it is doing for some unspecified reason (for example, you want it to re-check some condition, or just cease running, or anything else you can think of) then you need a mechanism to signal this. In particular, you'd want such a mechanism to ensure that any interruptable blocking operations, such as Thread.sleep(100000L) are interrupted. In other words, you can't just say: Whatever, it's up to the code itself, just, um, make an AtomicBoolean and check it a lot.
That's where the 'interrupt' system comes in. The idea is:
To interrupt any thread, raise its interrupt flag, with thatThread.interrupt();
All methods that do interruptable things should check this flag. The procedure is: If it is raised, then [A] clear it, and [B] handle the interruption, doing whatever the programmer intended to happen upon interruption (just stop running, or re-check some condition, re-read some config file, who knows - it's programming, whatever you want it to mean). If you CAN handle the notion of aborting some operation, but you CANNOT handle it, then instead clear that flag and throw InterruptedException, so that the caller can handle it.
As a result, any code that knows what 'I was interrupted!' means should BOTH check the flag (especially if that code has an event loop, which most thread-based code does have), AND catch InterruptedException from any method specced to throw it, and react in the exact same way to either catching that exception or having Thread.interrupted() return true.
Things go all sorts of wrong if you handle the fact that the interrupt flag is up, but you do NOT lower it. For example, if you abort your CPU-bound bitcoin mining or whatnot and just return back to your caller whilst leaving the flag up, then the next time caller invokes Thread.sleep, thread.sleep will notice the flag is up and IMMEDIATELY exit, not sleeping at all (exit by throwing InterruptedException, to be specific). That isn't intended. Hence why it is important that if you respond to an interrupt, you lower that flag.
So, let's go back to API design. There are two strategies:
Hypothetical design A
while (!Thread.currentThread().isInterrupted()) {
mineAnotherBitCoin();
}
Thread.currentThread().clearInterruptFlag();
Design B
while (!Thread.checkAndClearInterruptFlag()) {
mineAnotherBitCoin();
}
Note how design B is conceptually a lot shorter, does not have a 'gap' between checking the flag and clearing it, and therefore is fundamentally less error prone. Furthermore, for, well, reasons, it has been decided that raising an interrupt flag is something you can do to other threads (there is no point interrupting yourself, after all), but clearing one is a thing you can only do to your own thread.
B is what java actually has, except the method is somewhat strangely named interrupted(), and not checkAndClearInterruptFlag(). If you want an explanation of why some methods in java are somewhat suspectly named, it's because java does not like breaking backwards compatibility.
Fundamentally then, while they sound real similar, isInterrupted() and interrupted() do two very different things.
isInterrupted() is to check if some thread has already been interrupted and its response to this interruption is still pending (nothing has yet handled it).
interrupted() is something you put in the condition in your while loops that define the core body of your thread implementation (your 'event loop').
*) It doesn't help that the vast majority of examples of how to make threads in java are erroneous in that they don't properly do this. They tend to be while (true) or while (!running) {} or similar, either ignoring interruptions entirely or with a handrolled interrupt-esque 'running' concept.
So how do I know where to look?
Simple enough: If it's a thing that conceptually doesn't belong to any particular thread (such as 'how many threads are active right now'), or it is a utility concept (such as 'sleep'), or it is a thing that from a VM design principle can only be done to your own thread and not to anything else, then it is a static method in Thread.
If it's a thing that does belong to a particular thread AND the VM would let you do it to other threads (such as interrupting it, asking for its name, id, or priority, getting a stack dump, freezing this thread until the other thread completes, or setting its priority), then it's an instance method.
In many ways you can reverse this logic: If you want to do some thread related business, check the Thread class for something that seems to describe what you want. Then check if the method is static or not. If it is static, you don't get to do it to any other thread (such as clearing the interrupt flag, or sleep). If it's instance, you CAN do that to other threads (such as changing its priority level).
Because you can't make another thread sleep that is not the thread you are on. Even when you call Thread.currentThread().sleep(), you are calling the static method 'sleep'. If you were to call the sleep method on a different Thread object, it would still make the current thread sleep.
If you want to make a different thread sleep, you should set a flag that the other thread reads, which causes it to sleep.
is there any kind of Runnable, Callable or Thread with capability of stopping it in any duration of time?
I wrote something like this
public class ThreadRunner {
private ExecutorService threadPoolExecutor;
ThreadRunner() {
threadPoolExecutor = Executors.newSingleThreadExecutor();
}
public void startThread(String endPoint, ProgressBar progressBar) {
Runnable task = () -> {
// some code which saves images from URL (1230 images) and updates progress bar
};
threadPoolExecutor.execute(task);
}
public void stopThread() {
threadPoolExecutor.shutdownNow();
}
}
Thread runs correctly, images are being saved, progress bar being updated, but when I want to stop thread (or maybe even pause process of saving if possible) by calling ThreadRunner class's method - nothing happens.
Am I doing something wrong - or most likely - what am I doing wrong?
is there any kind of Runnable, Callable or Thread with capability of stopping it in any duration of time?
You can implement such a thing yourself, but there is no generic support available for it, unless you count the long-deprecated Thread.stop() methods. Under no circumstances should you use those methods, but do read their API docs for a discussion of why they are deprecated and what you can do instead. You can find a longer-form version of the discussion in Java's technical notes.
The bottom line is that the computation you want to be able to stop needs to periodically check some shared variable or built-in condition to determine whether to do so. You arrange for that variable to be set when you want the thread to stop, and if you need to block until it does stop then you join() it. Under some circumstances, it can be helpful to interrupt() the thread to get it to check the variable (or being interrupted can itself serve as the termination condition). The user-facing end of this can be wrapped up in a method.
In any case, an ExecutorService cannot give you a handle on this. Requesting such a service to shut down will prevent it from dispatching any more tasks, but there is no safe, general-purpose mechanism by which it could force a premature shutdown of tasks that are already running.
Once started, a thread will run until Runnable.run() exits. Due to several issues you should never use Thread.stop() or Thread.interrupt().
Instead, you will have to implement your own logic for exit/pause. A few suggestions:
For stopping the thread, you can make a boolean variable shouldExit. In your thread, check this variable every now and then, and just do "return" or break the for/while loop when it becomes true. Setting this variable from another thread should now make the downloader exit. If necessary, you should surround access to this variable with synchronized block as to prevent any race conditions.
For pausing the thread, you can use a similar approach. When you set a certain variable to true (e.g. isPaused), make the thread react by going into an Object.sleep(). This way, it won't consume any CPU during sleep. You can then use Object.notify() from another thread to "kick" the sleeping thread out ouf sleep. You will need a synchronized block here, too.
I've finally managed to implement Thread.interrupt() into my program instead of Thread.stop(). I am however not sure that I've done this well.
I have a class which extends Thread and declares several methods. EVERY method has been made to throw InterruptedException (Each method performs I/O intensive operations, some of which take several minutes to complete, I have therefore not used a thread-safe flag as the flag would not get checked until after the operation completed). I have also added the following code at several places within these methods to throw the exceptions:
if (this.isInterrupted()) throw new InterruptedException();
Within the run() method I execute all methods within a try/catch for InterruptedException. If caught, I execute Process.destroy() and BufferedReader.close() for my class variables.
This all works, and seems to work very well, however I have a couple of questions:
Is it correct to have more than 10 methods, all of which throw InterruptedException? Is there a better way to do this?
Is it correct to bloat the methods with checks for isInterrupted()?
At the end of the catch InterruptedException block, must I execute a 'return', or 'null' certain values to make the Thread available for GC? If I re-create the Thread it takes longer than usual to initialize.
Finally, are there any issues/enhancements related to what I've done?
Thanks in advance for your help!
Thread interruption in Java doesn't mean stopping the execution of that thread. It is not stop, it is interrupt. A thread can be interrupted when something fundamental and crucial changes, telling the thread that its execution context, its task or its enviroment changed in some significant way. A thread reaction to this message is implementation specific. It can be stop, it can be restart or any other action. A thread that doesn't handle interruptions cannot be interrupted, but its behaviour can still be altered, for example, by using a shared variable.
For example, imagine you have a number of threads, all searching through a part of a problem space for a solution. When one thread finds a solution, it can interrupt other threads, because their search for a solution is no longer relevant. A solution has already been found.
Or imagine one continuously working main thread and one network communication thread. Each time the network thread receives a messsage, it interrupts the working thread with the message. Based on what the message and the context is, the worker thread may decide what to do next. For example, if the message was "STOP", then it could stop all execution immediately. If the message was "RESET", it could start again from scratch or maybe not from scratch and reuse some previous work, based on the execution context.
Is it correct to have more than 10 methods, all of which throw
InterruptedException? Is there a better way to do this?
No, this is perfectly fine, as long as you know what you are doing. If you implement interruptions to just stop the threads, there is no need to throw InterruptedExceptions. A Thread's run() method is it's first, and the exception will not go any further the stack.
Is it correct to bloat the methods with checks for isInterrupted()?
Depending on the context. The checks would be usually added before some crucial code. Usually it is added as a first item in the loop block.
At the end of the catch InterruptedException block, must I execute a
'return', or 'null' certain values to make the Thread available for
GC? If I re-create the Thread it takes longer than usual to
initialize.
No. Once the Thread exists from the run() method, it's left at GC's mercy. Shared variables will not be GC'ed, as long as they are still referenced by other objects.