Due to the fact that in almost every question regarding the use of Thread.sleep it is mostly indicated to use it only in certain situations, I come to ask you if it is correct to use it in my case or if there is a better way to do it.
The operating system is Linux(Debian), in which a bash script is running that is detecting when a device (more specifically, a storage device) is inserted/removed, and then writes into a FIFO a string under the type "ADD {path-to-dev}" or "REM {path-to-dev}".
I created a small app in java which makes use of two threads. The first thread will call upon a read method that parses the String to the standard output, after which it will wait(). The second thread will check if the FIFO is empty or not and then, when it sees that a String has been inserted then it will call notify() so the other thread will print the String in there and so on. Inside the loop where it checks if the FIFO has data or not, I call Thread.sleep(1000), and I am unsure whether this is a good approach or not. I will present the code which handles all the action.
First, the class which has the methods of reading:
public class Detect {
private File file;
private BufferedReader read;
private volatile boolean readable;
private static String readFromFile;
public Detect() throws FileNotFoundException {
file = new File("/hardware_stuff/hardware_events");
read = new BufferedReader(new FileReader(file));
readable = true;
}
synchronized String readFromFifo() {
while (!readable) {
try {
wait();
} catch (InterruptedException ex) {
System.out.println("Interrupted during the wait for read.");
}
}
try {
while (read.ready()) {
readFromFile = read.readLine();
}
} catch (IOException ex) {
System.out.println("Error in reading from FIFO.");
}
readable = false;
notify();
return readFromFile;
}
synchronized void waitForFifo() {
while (readable) {
try {
wait();
} catch (InterruptedException ex) {
Logger.getLogger(Detect.class.getName()).log(Level.SEVERE, null, ex);
}
}
try {
while (!read.ready()) {
Thread.sleep(1000);
System.out.println("Sleeping due to lack of activity in FIFO in thread : " + Thread.currentThread().getName());
}
} catch (IOException | InterruptedException ex) {
Logger.getLogger(Detect.class.getName()).log(Level.SEVERE, null, ex);
}
readable = true;
notify();
}}
Next, the thread which will read from it.
public class ReadThread extends Thread {
Detect detect;
private boolean shouldBeRunning;
public ReadThread(Detect detect) {
this.detect = detect;
shouldBeRunning = true;
}
#Override
public void run() {
while (shouldBeRunning) {
String added = detect.readFromFifo();
System.out.println(added);
}
}
public void stopRunning() {
shouldBeRunning = false;
}}
Finally, the thread which will check if the FIFO is empty or not.
public class NotifyThread extends Thread {
Detect detect;
private boolean shouldBeRunning;
public NotifyThread(Detect detect) {
this.detect = detect;
shouldBeRunning = true;
}
#Override
public void run() {
while (shouldBeRunning) {
detect.waitForFifo();
}
}
public void stopRunning() {
shouldBeRunning = false;
}}
In main I just create the threads and start them.
Detect detect = new Detect();
NotifyThread nThread = new NotifyThread(detect);
ReadThread rThread = new ReadThread(detect);
nThread.start();
System.out.println("Started the notifier thread in : " + Thread.currentThread().getName());
rThread.start();
System.out.println("Started the reading thread in : " + Thread.currentThread().getName());
Is there any alternative to calling sleep or another approach I can take to replace the sleep with something else? I have already read other questions related to this topic and I am still uncertain/have not understood whether this sort of case is indicated for sleep or not.
UPDATE: As #james large said, there was no need to poll for ready. I was not aware that if there is no line, the readLine() will 'sleep' and there was no need to poll it after all. I removed the notifier thread, and I simply kept the ReadThread which will call the Detect readFromFifo() method and it all works good. #dumptruckman, thanks for the suggestion. Although it doesn't apply to my case, I didn't know of the WatchService and it was a good read, good stuff to know. #Nyamiou The Galeanthrope, the timer would have been useful, but as I already said, I only keep one thread to execute the same method and it works as intended.#Krzysztof Cichocki, thanks for pointing out there are issues. I was aware of that, otherwise I wouldn't have asked this question.
Related
I am trying to stop a long running method after 10 seconds of execution, so far i followed the timer instructions on baeldung.
https://www.baeldung.com/java-stop-execution-after-certain-time#1-using-a-timer
When the method is a simple call to a thread sleep it works, but when I call my function with sub methods it doesn't stop.
My implementation looks like this:
class TimeOutTask extends TimerTask {
private Thread t;
private Timer timer;
TimeOutTask(Thread t, Timer timer){
this.t = t;
this.timer = timer;
}
public void run() {
if (t != null && t.isAlive()) {
t.interrupt();
timer.cancel();
}
}
}
class Execution implements Runnable {
private String carpeta;
private Experiment exp;
public Execution(String carpeta, Experiment exp) {
this.carpeta = carpeta;
this.exp = exp;
}
#Override
public void run() {
try {
while (!Thread.currentThread().isInterrupted()) {
exp.executeExperiment(carpeta);
}
} catch (InterruptedException e) {
System.out.println("Fin de ejecución por tiempo");
}
}
}
And the way I am calling this execution is throught the executeTimedExperiment method
public Experiment() {
this.cases = new ArrayList<>();
}
private void executeTimedExperiment(String carpeta){
Thread t = new Thread(new Execution(carpeta,this));
Timer timer = new Timer();
timer.schedule(new TimeOutTask(t, timer), 10000);
t.start();
}
private void executeExperiment(String carpeta) throws InterruptedException {
String[] files = getFiles(carpeta);
Arrays.sort(files);
for (String file : files) {
executeCase(carpeta, file);
}
}
private boolean executeCase(String carpeta, String file) {
Graph g = readDataToGraph(carpeta + "/" + file);
Solution s = new ExactSolutionGenerator().ExactSolution(g);
addNewCase(file, s);
}
The executeExperiment method is the long running and I marked it with InterruptedException but the compiler tells me the exception is never throw.
What happens now when I execute it is that it runs normally without stoppping.
I am not sure if I need to add InterruptedException to the submethods or something else, but I would like to not touch the submethods if possible.
Thanks in advance.
You will need to do more than add throws InterruptedException to all of those ‘submethods’ (and your own methods). The body of each of those methods must be altered to properly respond to interrupts.
It is not possible to arbitrarily stop running code. Interrupts are cooperative—they only mean something if the thread being interrupted pays attention to them.
Your run() method does this properly: by placing the entire loop inside a try/catch, any InterruptedException will cause the loop to terminate and thus the thread will terminate.
But the methods it calls must do the same thing. Your run method calls executeExperiment, which does this:
String[] files = getFiles(carpeta);
I don’t know how long that method takes, but if it takes any significant amount of time at all (more than a fraction of a second), it needs to be capable of throwing InterruptedException in the middle of the file reading.
executeExperiment also calls executeCase, which calls the ‘submethods’ readDataToGraph, ExactSolution, and addNewCase. As above, each of those methods which takes more than a fraction of a second needs to respond to an interrupt by throw InterruptedException. So, I’m afraid you will need to modify them.
An example would be:
private Graph readDataToGraph(String filename)
throws InterruptedException {
Graph graph = new Graph();
try (BufferedReader reader = Files.newBufferedReader(Path.of(filename))) {
String line;
while ((line = reader.readLine()) != null) {
graph.addData(convertDataToGraphEntry(line));
if (Thread.interrupted()) {
throw new InterruptedException();
}
}
} catch (IOException e) {
throw new UncheckedIOException(e);
}
}
Compiler tells you the exception is never throw is beacuse your executeExperiment method is uninterruptable(Unlike some blocking methods, e.g. Object#wait), so thread.interrupt does not make the thread executing this method receive an InterruptedException.
Maybe you need to check whether the current thread has been interrupted every time you iterate files in your executeExperiment method, if it is, then throw an InterruptedException.(But this may still be inaccurate, because the executeCase method may be executed for a long time.)
Is there any way to get notifications in process when a thread changes state? I am writing a program that monitors thread state changes. I can poll each thread frequently but I would prefer something more reactive.
yes, use conditional variable, here is an example:
import java.util.concurrent.locks.*;
public class CubbyHole2 {
private int contents;
private boolean available = false; // this is your state
private Lock aLock = new ReentrantLock(); // state must be protected by lock
private Condition condVar = aLock.newCondition(); // instead of polling, block on a condition
public int get(int who) {
aLock.lock();
try {
// first check state
while (available == false) {
try {
// if state not match, go to sleep
condVar.await();
} catch (InterruptedException e) { }
}
// when status match, do someting
// change status
available = false;
System.out.println("Consumer " + who + " got: " +
contents);
// wake up all sleeper than wait on this condition
condVar.signalAll();
} finally {
aLock.unlock();
return contents;
}
}
public void put(int who, int value) {
aLock.lock();
try {
while (available == true) {
try {
condVar.await();
} catch (InterruptedException e) { }
}
contents = value;
available = true;
System.out.println("Producer " + who + " put: " +
contents);
condVar.signalAll();
} finally {
aLock.unlock();
}
}
}
The code you thread runs needs to be injected with code to make a call back which the state changes. You could do this by changing the code as #宏杰李 suggests or injecting the code with Instrumentation however polling the threads is likely to be simplest.
NOTE: The thread's state only tells you it's desired state from a JVM point of view. It doesn't show you
is it blocked on a blocking IO operation?
has it been context switched
has it been interrupted by the OS or the BIOS
has it been stopped for GC or code replacement
is it waiting for a lock on a static initialiser block. e.g. if it blocked waiting for the class to initialise it says it is RUNNING.
BTW Even the OS polls CPUs to see what they are doing, typically 100 times per second.
I have a Producer/Consumer situation where producer produces domains for the consumer to visit. The Consumer sends a https request and grabs the links from the page and submits them back to the producer. When the Producer finishes, the consumer does not and hangs on the final domain. I cannot for the life of my figure out why this is happening.
I have simplified my question
Main:
public class Main {
public static void main(String[] args) throws InterruptedException {
try
{
Broker broker = new Broker();
ExecutorService threadPool = Executors.newFixedThreadPool(3);
threadPool.execute(new Consumer(broker));
threadPool.execute(new Consumer(broker));
Future producerStatus = threadPool.submit(new Producer(broker));
// this will wait for the producer to finish its execution.
producerStatus.get();
threadPool.shutdown();
}
catch (Exception e)
{
e.printStackTrace();
}
}
}
Broker:
public class Broker {
private BlockingQueue<String> QUEUE = new LinkedBlockingQueue<String>();
public Boolean continueProducing = Boolean.TRUE;
public void put(String data) throws InterruptedException
{
this.QUEUE.put(data);
}
public String get() throws InterruptedException
{
//return this.queue.poll(1, TimeUnit.SECONDS);
return this.QUEUE.take();
}
}
Consumer:
public class Consumer implements Runnable{
private Broker broker;
public Consumer(Broker broker) {
this.broker = broker;
}
#Override
public void run() {
try {
String data = broker.get();
while (broker.continueProducing || data != null)
{
Thread.sleep(1000);
System.out.println("Consumer " + Thread.currentThread().getName() + " processed data from broker: " + data);
data = broker.get();
}
System.out.println("Comsumer " + Thread.currentThread().getName() + " finished its job; terminating.");
} catch (InterruptedException e) {
// TODO Auto-generated catch block
Thread.currentThread().interrupt();
e.printStackTrace();
}
}
}
Producer:
public class Producer implements Runnable{
private Broker broker;
public Producer(Broker broker) {
this.broker = broker;
}
#Override
public void run() {
try
{
for (int i = 0; i < 2; ++i) {
System.out.println("Producer produced: " + "https://example" + i + ".com");
Thread.sleep(100);
broker.put("https://example" + i + ".com");
}
//broker.put("https://example.com/2");
this.broker.continueProducing = Boolean.FALSE;
System.out.println("Producer finished its job; terminating.");
}catch(Exception e)
{
e.printStackTrace();
Thread.currentThread().interrupt();
}
}
}
Updated answer:
When I run your code, the consumer gets stuck on the line data = broker.get(). The broker is calling the BlockingQueue.take method. Here's the Javadoc for this method (emphasis mine):
Retrieves and removes the head of this queue, waiting if necessary until an element becomes available.
That means that even if the producer isn't producing anything, the consumer will still wait for something to be produced.
One possible solution for you would be to use a "poison pill" approach. Assuming that you only ever have one producer, your Broker class could look like this:
public class Broker {
private static final String POISON_PILL = "__POISON_PILL__";
private BlockingQueue<String> queue = new LinkedBlockingQueue<>();
public void put(String data) {
queue.add(data);
}
public void doneProducing() {
queue.add(POISON_PILL);
}
public String get() throws InterruptedException {
String result = queue.take();
if (result.equals(POISON_PILL)) {
queue.add(POISON_PILL);
return null;
} else {
return result;
}
}
}
Answer for previous code:
It would be great if you could narrow the scope of this question so that it included only the minimum amount of code to get the deadlock. As it currently is, there's a lot of code that you're posting that is not relevant, and there's some code that is relevant that you're not posting.
Additionally, there are a lot of problems with your current code. Your toLinkedHashSet method does not compile. In your add method, you're calling the BlockingQueue.put method even though your BlockingQueue should never hit its limit. You claim to want Ο(1) time for contains, but your code has Ο(n) time. You also seem to be doing a lot of unnecessary copying in your addAll and contains methods.
There's not enough information here for me to know what the problem is, but one thing that could be causing your problem is in your get method. If the consumer thread is interrupted, then your get method will cause it to uninterrupt itself (which probably wouldn't lead to a deadlock, but could look like one). In Java, it's very rarely acceptable to ignore an exception. If your call to the take method throws an InterruptedException, it's for a reason: another thread wants the current thread to stop. Your get method should throw InterruptedException. For example:
public String get() throws InterruptedException {
return unprocessed.take();
}
If you really need the get method to not throw an InterruptedException, you could throw some other chained exception containing the InterruptedException. If it's really appropriate to return "" on interruption, you could do something like this:
public String get() {
try {
return unprocessed.take();
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
return "";
}
}
By interrupting the current thread, you are making sure that at least the current thread is marked as interrupted, so something down the line could deal with it. But throwing InterruptedException is probably most appropriate if possible.
I still don't understand why you're creating your own wrapper for LinkedBlockingQueue, as opposed to just using a LinkedBlockingQueue on its own. It seems like everything you're adding on top of LinkedBlockingQueue is doing nothing but slowing it down.
When I tried to figure out how to stop a thread in a program with multiple threads,
I was suggested to call a method which actually sets a flag to tell that thread stop doing real works,like this:
public class ThreadTobeTerminated implements Runnable {
private static final Logger LOGGER = LoggerFactory.getLogger(IndexProcessor.class);
private volatile boolean running = true;
public void terminate() {
running = false;
}
#Override
public void run() {
while (running) {
try {
LOGGER.debug("Doing some real work ,like Counting...");
for(int i=0;i<100;i++){}
} catch (InterruptedException e) {
LOGGER.error("Exception", e);
running = false;
}
}
}
}
when I want to stop this tread ,I'll call threadInstance.terminate();.
Don't I need to literally stop this thread ?
Why I should leave this thread to do some useless work (method run called ,test the flag running==false then return)? I mean :this is a waste of time ,isn't it?
When the execution scope goes beyond the run() method, the thread stops, so the moment that the while loop is broken, the thread will stop.
This would also allow you to do some clean up if the situation requires it:
public void run() {
while (running) {
try {
LOGGER.debug("Doing some real work ,like Counting...");
for(int i=0;i<100;i++){}
} catch (InterruptedException e) {
LOGGER.error("Exception", e);
running = false;
}
}
//Clean up
}
The above approach allows you some control over how is the thread stops and what happens after as opposed to potentially just kill it, which could cause all kinds of problems.
Is there a standard nice way to call a blocking method with a timeout in Java? I want to be able to do:
// call something.blockingMethod();
// if it hasn't come back within 2 seconds, forget it
if that makes sense.
Thanks.
You could use an Executor:
ExecutorService executor = Executors.newCachedThreadPool();
Callable<Object> task = new Callable<Object>() {
public Object call() {
return something.blockingMethod();
}
};
Future<Object> future = executor.submit(task);
try {
Object result = future.get(5, TimeUnit.SECONDS);
} catch (TimeoutException ex) {
// handle the timeout
} catch (InterruptedException e) {
// handle the interrupts
} catch (ExecutionException e) {
// handle other exceptions
} finally {
future.cancel(true); // may or may not desire this
}
If the future.get doesn't return in 5 seconds, it throws a TimeoutException. The timeout can be configured in seconds, minutes, milliseconds or any unit available as a constant in TimeUnit.
See the JavaDoc for more detail.
You could wrap the call in a FutureTask and use the timeout version of get().
See http://java.sun.com/j2se/1.5.0/docs/api/java/util/concurrent/FutureTask.html
See also Guava's TimeLimiter which uses an Executor behind the scenes.
It's really great that people try to implement this in so many ways. But the truth is, there is NO way.
Most developers would try to put the blocking call in a different thread and have a future or some timer. BUT there is no way in Java to stop a thread externally, let alone a few very specific cases like the Thread.sleep() and Lock.lockInterruptibly() methods that explicitly handle thread interruption.
So really you have only 3 generic options:
Put your blocking call on a new thread and if the time expires you just move on, leaving that thread hanging. In that case you should make sure the thread is set to be a Daemon thread. This way the thread will not stop your application from terminating.
Use non blocking Java APIs. So for network for example, use NIO2 and use the non blocking methods. For reading from the console use Scanner.hasNext() before blocking etc.
If your blocking call is not an IO, but your logic, then you can repeatedly check for Thread.isInterrupted() to check if it was interrupted externally, and have another thread call thread.interrupt() on the blocking thread
This course about concurrency https://www.udemy.com/java-multithreading-concurrency-performance-optimization/?couponCode=CONCURRENCY
really walks through those fundamentals if you really want to understand how it works in Java. It actually talks about those specific limitations and scenarios, and how to go about them in one of the lectures.
I personally try to program without using blocking calls as much as possible. There are toolkits like Vert.x for example that make it really easy and performant to do IO and no IO operations asynchronously and in a non blocking way.
I hope it helps
There is also an AspectJ solution for that with jcabi-aspects library.
#Timeable(limit = 30, unit = TimeUnit.MINUTES)
public Soup cookSoup() {
// Cook soup, but for no more than 30 minutes (throw and exception if it takes any longer
}
It can't get more succinct, but you have to depend on AspectJ and introduce it in your build lifecycle, of course.
There is an article explaining it further: Limit Java Method Execution Time
I'm giving you here the complete code. In place of the method I'm calling, you can use your method:
public class NewTimeout {
public String simpleMethod() {
return "simple method";
}
public static void main(String[] args) {
ExecutorService executor = Executors.newSingleThreadScheduledExecutor();
Callable<Object> task = new Callable<Object>() {
public Object call() throws InterruptedException {
Thread.sleep(1100);
return new NewTimeout().simpleMethod();
}
};
Future<Object> future = executor.submit(task);
try {
Object result = future.get(1, TimeUnit.SECONDS);
System.out.println(result);
} catch (TimeoutException ex) {
System.out.println("Timeout............Timeout...........");
} catch (InterruptedException e) {
// handle the interrupts
} catch (ExecutionException e) {
// handle other exceptions
} finally {
executor.shutdown(); // may or may not desire this
}
}
}
Thread thread = new Thread(new Runnable() {
public void run() {
something.blockingMethod();
}
});
thread.start();
thread.join(2000);
if (thread.isAlive()) {
thread.stop();
}
Note, that stop is deprecated, better alternative is to set some volatile boolean flag, inside blockingMethod() check it and exit, like this:
import org.junit.*;
import java.util.*;
import junit.framework.TestCase;
public class ThreadTest extends TestCase {
static class Something implements Runnable {
private volatile boolean stopRequested;
private final int steps;
private final long waitPerStep;
public Something(int steps, long waitPerStep) {
this.steps = steps;
this.waitPerStep = waitPerStep;
}
#Override
public void run() {
blockingMethod();
}
public void blockingMethod() {
try {
for (int i = 0; i < steps && !stopRequested; i++) {
doALittleBit();
}
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
}
public void doALittleBit() throws InterruptedException {
Thread.sleep(waitPerStep);
}
public void setStopRequested(boolean stopRequested) {
this.stopRequested = stopRequested;
}
}
#Test
public void test() throws InterruptedException {
final Something somethingRunnable = new Something(5, 1000);
Thread thread = new Thread(somethingRunnable);
thread.start();
thread.join(2000);
if (thread.isAlive()) {
somethingRunnable.setStopRequested(true);
thread.join(2000);
assertFalse(thread.isAlive());
} else {
fail("Exptected to be alive (5 * 1000 > 2000)");
}
}
}
You need a circuit breaker implementation like the one present in the failsafe project on GitHub.
Try this. More simple solution. Guarantees that if block didn't execute within the time limit. the process will terminate and throws an exception.
public class TimeoutBlock {
private final long timeoutMilliSeconds;
private long timeoutInteval=100;
public TimeoutBlock(long timeoutMilliSeconds){
this.timeoutMilliSeconds=timeoutMilliSeconds;
}
public void addBlock(Runnable runnable) throws Throwable{
long collectIntervals=0;
Thread timeoutWorker=new Thread(runnable);
timeoutWorker.start();
do{
if(collectIntervals>=this.timeoutMilliSeconds){
timeoutWorker.stop();
throw new Exception("<<<<<<<<<<****>>>>>>>>>>> Timeout Block Execution Time Exceeded In "+timeoutMilliSeconds+" Milli Seconds. Thread Block Terminated.");
}
collectIntervals+=timeoutInteval;
Thread.sleep(timeoutInteval);
}while(timeoutWorker.isAlive());
System.out.println("<<<<<<<<<<####>>>>>>>>>>> Timeout Block Executed Within "+collectIntervals+" Milli Seconds.");
}
/**
* #return the timeoutInteval
*/
public long getTimeoutInteval() {
return timeoutInteval;
}
/**
* #param timeoutInteval the timeoutInteval to set
*/
public void setTimeoutInteval(long timeoutInteval) {
this.timeoutInteval = timeoutInteval;
}
}
example :
try {
TimeoutBlock timeoutBlock = new TimeoutBlock(10 * 60 * 1000);//set timeout in milliseconds
Runnable block=new Runnable() {
#Override
public void run() {
//TO DO write block of code
}
};
timeoutBlock.addBlock(block);// execute the runnable block
} catch (Throwable e) {
//catch the exception here . Which is block didn't execute within the time limit
}
In special case of a blocking queue:
Generic java.util.concurrent.SynchronousQueue has a poll method with timeout parameter.
Assume blockingMethod just sleep for some millis:
public void blockingMethod(Object input) {
try {
Thread.sleep(3000);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
My solution is to use wait() and synchronized like this:
public void blockingMethod(final Object input, long millis) {
final Object lock = new Object();
new Thread(new Runnable() {
#Override
public void run() {
blockingMethod(input);
synchronized (lock) {
lock.notify();
}
}
}).start();
synchronized (lock) {
try {
// Wait for specific millis and release the lock.
// If blockingMethod is done during waiting time, it will wake
// me up and give me the lock, and I will finish directly.
// Otherwise, when the waiting time is over and the
// blockingMethod is still
// running, I will reacquire the lock and finish.
lock.wait(millis);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
So u can replace
something.blockingMethod(input)
to
something.blockingMethod(input, 2000)
Hope it helps.