There are two or more threads: main and several children. Children are workers, main controls children liveness. Once main thread detects a child thread is dead it creates new thread.
Currently I can't imagine better solution than checking t.isAlive() on each thread in a loop but it is well known that developers should avoid polling at any cost.
Note. Worker thread can wait several minutes on HTTP response (getInputStream() on URLConnection)
UPDATE
Worker doesn't finish its job but after it received a response or on timeout it creates new connection and awaiting for server response again.
You shouldn't use low level Thread methods if you don't really need them. Instead, use Java Concurrency API. For your case, I would use a thread pool which controls the threads. If a thread finishes its job, it returns to the pool rather than really dying.
According to the purposes in your question and our "dialog" in comments, I suggest you following simple idea.
if you want to recreate thread with same functionallity, why do you allow threads to die?
If you have, as you said, 3-d party threads implementation, you can wrap them into another thread and do not allow them to die.
Consider, 3-d party Thread implementation is called ThirdPartyThread class. So, instead of checking their state with .isAlive(), just wrap it into another thread with try ... catch:
new Thread(new Runnable() {
#Override
public void run() {
do {
try {
new ThirdPartyThread().run();
} catch (Throwable t) {
// you can vary behaviour here with different classes of exceptions.
// But main idea is to catch their death and go on
}
} while (true); // instead of `true` you can use your specific condition
}
}).start();
Andremoniy: if you want to recreate thread with same functionallity, why do you allow threads to die?
gumkins: For example I can't fix uncaught exceptions in third-party code.
If it doesn't make sense to catch the exception, and continue running in the same thread, then it won't make any sense to start a new thread to take the old thread's place. Starting a new thread accomplishes nothing.
All threads share the same heap and the same global state. If the library keeps global state in static variables or singleton objects, then that same state will be visible in every thread. If the global state is broken/invalid after some exception, then it's going to be invalid/broken in every thread. (And that includes any new threads that your program creates after the damage was done.)
Incidentally, the wheel that you are trying to re-invent here has a name: It's called a "thread pool."
The Java standard library provides a number of different kinds of thread pool which all implement the java.util.concurrent.ExecutorService interface. You should check it out.
Related
I'm new to web programming, and I've created a server class that forks off ClientProcess threads to service each client's connection. Currently I have 2 problems:
Keeping track of running threads
Shutting down the threads once execution finishes and closing connections (the topic of this thread)
For problem one, I'm currently using an Arraylist<ClientProcess> to hold a list of threads and call Thread.interrupt() at the appropriate time. I know that the java API contains a class ThreadGroup that is supposed to perform this task but I don't know how I'm supposed to add threads to the group or if that just happens automatically when I call Thread.start(). In other words, I have already solved this problem but if anyone knows a better way to perform this I'm open to implement one.
For problem two, I still have no clue how to begin. I've read the article about Thread.stop by Oracle but I don't understand their recommendation for how to interrupt/stop the thread. For reference, my ClientProcess class looks something like this:
public class ClientProcess extends Thread {
private Socket clientConnection;
/* class constructor, etc. */
#Override
public void run() {
try (BufferedReader in = new BufferedReader(clientConnection.getInputStream());
PrintWriter out = new PrintWriter(clientConnection.getOutputStream())) {
while (in.hasNext()) { /* do stuff */ }
} catch (InterruptedException e) {
/* close connection, clean resources, etc. */
}
}
}
From the article, it looks like I'm supposed to be storing a reference to the thread in the class (why?) and that I'm supposed to set the variable to null when I want to stop the thread from running, then check for null anywhere that the thread may stop. I don't see a reason for my thread to hold a reference to itself or to have to check if it's null with every single branch statement that I need to perform in run(). I'm open to a complete refactor of the code (this project is still in its early stages) but I'm just looking for anyone to point me in the right direction.
Edit: The question already has a few answers, but I realized that my real question is very different than what I asked. I'm trying to learn modern techniques for web programming, and I remembered that a few years ago I read in a C++ web programming book that multithreading is typically used in order to service clients. After poking around a bit on the web I've seen that web programming has evolved to fit demand and now uses completely different paradigms. What I really should have asked was something along the lines of 'How do I Create a Server that can Handle Taskes Asynchronously' or 'What are some Modern Programming Paradigms for Server/Client Architectures?' The real answer to this question is that multithreading is no longer considered tractable and that there are other paradigms that I should be using to solve this problem.
If you make blocking calls that throw an interrupt exception, then interrupting the thread will cause an interrupt exception. Otherwise, you'll have to explicitly check if the thread has been interrupted. You should have an executor service for starting your class.
ExecutorService executor = Executors.newFixedThreadPool(2);
Then submit tasks:
Future<?> f = executor.submit( ()->{
try (BufferedReader in = new BufferedReader(clientConnection.getInputStream());
PrintWriter out = new PrintWriter(clientConnection.getOutputStream())) {
while (in.hasNext()) { /* do stuff */ }
} catch (InterruptedException e) {
//try with resources takes care of the streams.
return;
}
} );
Then when you need to shutdown all you have to do is.
executor.shutdownNow();
Then your currently running tasks will be interrupted. There are execution services with more features to, and you can use the futures to control the task.
1) Keeping track of running threads
I know that the java API contains a class ThreadGroup that is supposed to perform this task but I don't know how I'm supposed to add threads to the group
Yeah, using your own collection of threads, or even better an ExecutorService, to manage your threads is the right thing to do. I've written a large number of Java threaded applications and never had to use a ThreadGroup.
2) Shutting down the threads once execution finishes and closing connections
Unfortunately, you cannot use thread.interrupt() to cause an IO method to throw InterruptedException because none of the IO methods throw that exception unless you are using NIO's InterruptibleChannel or other special classes. If you are interrupting a thread that is processing something, you can test for Thread.currentThread().isInterrupted() but not when you are blocking on IO.
The right thing to do here would be to close the client socket out from under it. I would add a clientProcess.close() method which closes the Socket clientConnection.
public void close() throws IOException {
clientConnection.close();
}
This will then cause the client thread which is reading on that socket to get an IOException when it goes to read from the socket which it can catch and return to stop running.
From the article, it looks like I'm supposed to be storing a reference to the thread in the class (why?) and that I'm supposed to set the variable to null when I want to stop the thread from running
If your thread is looping around, it is common to use a volatile field which could be set by the caller to cause the looping thread to stop. But in your case, the thread is waiting on IO and not in a processing loop so I think closing the socket is the way to go.
and excuse the lack of knowledge on multithreaded apps, but I am new to the field.
Is there a pattern or common used methodology for monitoring the 'job completion' or 'job status' of worker threads from a monitor (a class that acts as a monitor)?
What I have currently done is create a list of workers and create one thread for each worker. After all threads have started i am looping over the worker list and 'checking their status' by making a call to a method.
At that time I couldn't come up with a different solution, but being new to the field, I don't know if this is the way to go, or if there are other solutions or patterns that I should study.
Depending on what you want, there are many ways that you can do this.
If you just want to wait until all the threads finish (i.e. all you care about is having everything finish before moving on), you can use Thread.join():
try {
for (Thread t: threadsIWaitOn)
t.join();
} catch (InterruptedException iex) {
/* ... handle error ...
}
If you want a more fine-grained control over the thread status and want to be able, at any time, to know what threads are doing, you can use the Thread.getState() function. This returns a Thread.State object that describes whether the thread is running, blocked, new, etc., and the Javadoc specifically says that it's designed for monitoring the state of a thread rather than trying to synchronize on it. This might be want you want to do.
If you want even more information than that - say, how to get a progress indicator for each thread that counts up from 0 to 100 as the thread progresses - then another option might be to create a Map from Threads to AtomicIntegers associating each thread with a counter, then pass the AtomicInteger into the constructor of each thread. That way, each thread can continuously increment the counters, and you can have another thread that continuously polls the progress.
In short, you have a lot of options based on what it is that you're trying to accomplish. Hopefully something in here helps out!
Use a ThreadPool and Executor, then you get a Future<> and you can poll for their completion and some more nice stuff, too. I can appreciate this book for you: Java Concurrency in Practice
Try to use any kind of synchronization. For example, wait on some kind of monitor/semaphore until job is done / whatever you need.
I've been trying to teach myself concurrency, and I've run into an issue. I understand that two Java threads can communicate to each other via wait() and notify(). However, this requires one thread to be inactive and essentially "just sitting around" until the other one wakes it up.
Is it possible to have both threads running simultaneously and still have them listening for notifications from the other? Would this be accomplished through concurrency techniques or instead something like an ActionListener?
For example, the project I'm testing this on is basically a grid where different entities wander around through different cells. When two of the entities happen to wander into the same cell, I'd like one to notify the other and something different to happen based on this (for instance, a greeting: "Hello there!"). But as it stands, with the wait/notify paradigm, one of the threads/entities has to simply sit in one cell waiting for another to wander in; they can't both move around.
There's a few ways you can communicate between threads. Using the most common approach you can use instance variables to share info between threads but you must take care to only write from one thread or synchronize any updates to the shared variable. Alternatively you can use Piped I/O streams which were designed for inter-thread communication, or passing raw data between threads. One thread writes info to the stream while the other reads it.
Here's an example method that would read output from a slow network connection and dump it to System.out using threads.
public void threads() throws IOException {
final PipedOutputStream outputForMainThread = new PipedOutputStream();
new Thread(new Runnable() {
#Override
public void run() {
while(moreDataOnNetwork()) {
byte[] data = readDataFromNetwork();
try {
outputForMainThread.write(data);
} catch (IOException e) {
e.printStackTrace();
}
}
}
}).start();
BufferedReader reader = new BufferedReader(new InputStreamReader(new PipedInputStream(outputForMainThread)));
for(String eachLine = reader.readLine(); eachLine != null; eachLine = reader.readLine()) {
System.out.println(eachLine);
}
}
However it almost sounds like you want an event callback mechanism where one thread (your user interface thread) is notified when the other thread detects a certain condition. Depending on your platform much of this is baked in. Using Android, for eg., you could have a thread that determines that a grid entity moved. It would send an update to the main user interface thread to repaint the screen. Such an update could resemble:
public void gridEntityDidUpdate(final Point fromLocation, final Point toLocation) {
Activity activity = getMainActivity();
activity.runOnUiThread(
new Runnable() {
#Override
public void run() {
updateScreen(fromLocation, toLocation);
if(pointsAreCoincedent(fromLocation, toLocation)) {
System.out.println("Hello there!");
}
}
}
);
}
private void updateScreen(Point fromLocation, Point toLocation) {
//Update the main activity screen here
}
In this scenario you have a background thread that works out the position of all on-screen elements and notifies the main thread when elements positions change. There is an extracted method that determines if 2 points are coincidental or the same.
You can use Erlang language to communicated safely among the Processes which runs within there own Address space along with Java as a better and safe alternative to thread.
I've been trying to teach myself concurrency, and I've run into an issue. I understand that two Java threads can communicate to each other via wait() and notify().
The "classic" Java threading tutorials teach wait/notify early on. Back around the Java 1.1, 1.2 time frame that's all there was.
However if you can get a copy of the excellent "Java Concurrency in Practice" by Brian Goetz, wait/notify are not discussed until chapter 14 "Building Custom Synchronizers" in section IV advanced topics. I am severely paraphrasing here, but the impression I got was "OK if you've read the 300 previous pages and none of the building blocks discussed so far meet your needs, then you can try building your own using wait/notify".
My point is that wait/notify, although very important, might not be the best place to start learning concurrency. Some of the answers/comments in this question (producer/consumer, ExecutorService) are referring to the higher level concurrency building blocks that were added in Java 5. Even though this stuff was added later, it's the stuff you should be learning first.
Back to your question - here are a couple of thoughts:
If this is a GUI application and you want to have a background thread do some work, check out SwingWorker. I have had success using a SwingWorker (section 9.3.3) where the background thread reads messages from a blocking queue (section 5.3) does some work and notifies the GUI thread by invoking the higher level "publish" method. No "wait/notify" - at least not in my code.
If the application is not Swing-based and you want to have different threads performing tasks in parallel and occasionally send messages to each other, consider ZeroMQ "The socket library that acts as a concurrency framework." With ZeroMQ, each thread is running an event loop which reads and processes messages. A thread can schedule work on it's own thread by sending itself a message. It can schedule work/notify a different thread by sending a message to that thread (socket).
Anyhow, good luck.
Try using ThreadManager class, which has List<Thread> and is kind of like a semaphore object. Your threads should be able to find and reference other threads from there.
Is it possible to have both threads running simultaneously and still have them listening for notifications from the other?
Whenever they are not waiting, they can be doing something at the same time. If they appear to be just waiting for each other it is likely you are better off with one thread. (Using multiple threads is not always better)
Would this be accomplished through concurrency techniques or instead something like an ActionListener?
It is more likely to be a design issue with how you have broken down the problem. Threads work best when there is a minimum of interaction between them. If they are highly dependent on each other you should consider using less threads.
But as it stands, with the wait/notify paradigm, one of the threads/entities has to simply sit in one cell waiting for another to wander in;
I don't see why you need wait/notify here at all. I would just have them move around and send messages to one another when they are in the same cell.
Ok.... Let me try to explain this the best I can....
Also: this is for a mod within minecraft.
Okay, so I created a thread object
public static Thread KillThread = new Thread();
Then in the constructor of my main class which is called when the game(Mine craft starts) I have
KillThread = new Thread(new KillAuraThread());
KillAuraThread is the name of the class that is the thread..
So I created a thread now. Is where it's pissing me off
The thread will run for exactly 1 second, and It can not be running multiple times or it will ruin the point of the delaying and threading.
if(KillAura.enabled && !KillThread.isAlive())
{
System.out.println("Go AURA!");
try
{
KillThread.start();
}catch (Exception e)
{
e.printStackTrace();
}
}
That is called every tick within the game where it would send position updates and such.
Now here is where I'm having the problem. Once the thread starts it becomes "alive" and when it ends it is no longer "alive". But can threads only be started once? because after the first run it's no longer working? And ideas? Links?
Yes Threads can only be started once, you cannot reuse a Thread object.
It is never legal to start a thread more than once. In particular, a
thread may not be restarted once it has completed execution. See java.lang.Thread.start()
Regardless of this fact, do not use the Thread.State for thread lifecycle management.
You're right, threads can run only once and it's illegal to start/run a thread more than once. You should consider using a while loop to keep your thread alive.
Instead of directly dealing with Threads, you should be using the classes inside the java.util.concurrent package to schedule a fixed task at regular intervals which is apparently what you're trying to do. Take a look at ThreadPoolExecutor.
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Java: “implements Runnable” vs. “extends Thread”
I'm just wondering is there some subtle difference between creating your own custom object that extends Thread and creating a thread using the Thread(Runnable) constructor?
I have some code that works fine when I use classes that extend Thread, but if I try to use logic that creates Threads by using the Thread(Runnable) constructor the new threads do not seem to work properly - I can't detect that they are alive in the same way as when I use the custom sub-classes I made and they do not seem to end, ever.
In my code I'm just spawning a few threads then searching through my list of threads to find one that is alive and joining with it until it dies. Then I once again search for a thread in the list that is alive and join to it.. this continues until all threads die.
Thanks for reading.
A Thread is a resource for doing work. A Runnable is a piece of work. Are you creating a new type of resource, or just defining the work you want done?
To 'end' the thread you simply return from the 'run' method. Would need to see an example of your code to see what you mean about not being able to tell if they're active.
Creating Runnables also of course makes it easier to refactor your code to use a ThreadPool in the future.
In my code I'm just spawning a few threads then searching through my list of threads to find one that is alive and joining with it until it dies.
How (and why) are you "searching through my list of threads"? I would instead add the Thread to some sort of Collection that you then can then iterate across and join with each Thread in turn:
List<Thread> threads = new ArrayList<Thread();
for (int i = 0; i < 100; i++) {
Thread thread = new Thread(new Runnable() ...);
thread.start();
threads.add(thread);
}
...
for (Thread thread : threads) {
thread.join();
}
Even better would be to use one of the ExecutorServices given by Executors. They have a lot of features around creating thread-pools and waiting for the pool to completely finish. Almost always recommended over new Thread(...).
I can't detect that they are alive in the same way as when I use the custom sub-classes I made
If you are trying to set the name of the Thread then you can't do this in the constructor of your Runnable. You can however do this in the run() method. You can do:
new Thread(new Runnable() {
public void run() {
Thread.currentThread().setName("...");
}
});
Otherwise, I'm not sure why you wouldn't be seeing your Thread unless it has already finished.
they do not seem to end, ever.
Using a Runnable, the thread finishes when the run() method returns -- either through a return or a throw. This is very much the same as extending Thread so I'm not sure why this wouldn't work.
I would really recommend to use the concurrency utility and not trying to manage yourself the Threads, which is complicated and error prone.
Using the concurrent api will also help you to apply the right patterns straight away.