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.
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.
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.
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 am writing a simple top down space game, and am extending it to allow play over a network with multiple players. I've done a fair bit of reading, but this is the first time I've done this and I'd appreciate some advice on choosing a sensible design.
My GUI is written using Swing. 30 times a second, a timer fires, and repaints my GUI according to data in a gameWorld object in memory (essentially a list of ships & projectiles with positions, etc). Physics updates of the gameWorld are also carried out using this timer. Thus, for the single player implementation, everything happens on the EDT, and this works fine.
Now, I have separate thread dealing with incoming packets from other players. I would like to update the data in my gameWorld object based on what these packets contain. My question is, should I use invokeLater to make these changes, or should I use locks to avoid concurrency problems?
To illustrate what I mean:
runMethodOfInputThread() {
while(takingInput) {
data = receiveAndInterpretIncomingPacket(); // blocks
SwingUtilities.invokeLater(new Runnable() {
public void run() {
gameWorld.updateWithNewGameInfo(data);
}
});
}
}
vs
runMethodOfInputThread() {
while(takingInput) {
data = receiveAndInterpretIncomingPacket(); // blocks
synchronize (gameWorldLock) {
gameWorld.updateWithNewGameInfo(data);
}
}
}
The latter would also require using similar synchronize blocks wherever the EDT accesses the gameWorld, so it seems to me that using invokeLater would be simpler to implement. But am I right in thinking both approaches would work? Are there any other significant pros/cons to bear in mind?
Thanks,
Jeremy
Well, first of all you don not need to choose only one method. You can use locks to make you data structure thread-safe "just to be sure" (since your application is already multithreaded), and use invokeLater to actually apply changes only in EDT -- and in this case JIT likely to optimize you locks down, close to 0.
Next, from my point of view invokeLater is rather preferred way: if you can way around dealing with multi-threaded -- you should use the way, just because multithreading is hard and rich of possible errors.
But applying changes via invokeLater() will put additional pressure on EDT, so, if changes come with high rate you can observe GUI degradation. Also, if gameWorld.updateWithNewGameInfo(data) is havy method taking observable time to complete, it can makes you GUI even freeze. Also, invokeLater puts your task at the tail of event queue, so it'll be done after all events currently in queue. It may -- in some cases -- cause delays in applying changes, which can makes you game less user-friendly. It may, or may not be your case, but you'll should keep it in mind
As for general rule -- not use EDT for any time consuming task. As far, as I understand, network packet parsing is already in seperate thread in your application. Applying changes can (and should) be done in separate thread too, if it is time consuming.
Pros for approach 1:
Minimized complexity
Stability
By restricting access to the 'gameWorld' variable to the EDT thread, locking mechanisms are not required. Concurrent programming is complex and requires the programmer(s) to be vigilant throughout the source base when accessing objects shared amongst threads. It is possible for
a programmer to forget to synchronize in certain instances, leading to compromised game states or program failure.
Pros for approach 2:
Scalability
Performance
Minimizing the processing done on the EDT thread ensures that the games interface and display will remain responsive to the user. Approach 1 may work for now, but later revisions of your game will not be able to scale to a more advanced interface if the EDT thread is busy doing non-ui processing.
Not the second one. You want to have as little as possible running in the EDT. If you are waiting for a lock in the EDT, it's as bad as running all the other code (on the other side of the lock) directly in the EDT since the EDT has to wait for everything else to finish.
Also, it seems that your whole game is running on the EDT. That's bad practice. You should split your code using the model-view-controller pattern. I understand your game is small and can run in the EDT, but you should probably not get into the habit.
You should have your game logic running from a timer thread (java.util.concurrent.ScheduledThreadPoolExecutor) and at the end of every period you "send" your data to the EDT and repaint with invokeLater.
You should also have some separate thread that reads the socket and that thread should write to objects that share locks with the objects you are using in the timer game thread.
My suggestion is as follows
push all loaded data from different users (thread) to a queue
use another thread to read from that queue and update UI from EDT
It should avoid your concurrency issue. How it can be achived
runMethodOfInputThread() {
while(takingInput) {
data = receiveAndInterpretIncomingPacket(); // blocks
blockingQueue.add(data);
}
}
runMethodOfUPdateUIThread() {
while(updatingUI) {
data = blockingQueue.take();
SwingUtilities.invokeLater(new Runnable() {
public void run() {
gameWorld.updateWithNewGameInfo(data);
}
});
}
}
Im working on a java application that involves threads. So i just wrote a piece of code to just familiarize myself with the execution of multiple yet concurrent threads
public class thready implements Runnable{
private int num;
public thready(int a) {
this.num=a;
}
public void run() {
System.out.println("This is thread num"+num);
for (int i=num;i<100;i++)
{
System.out.println(i);
}
}
public static void main(String [] args)
{
Runnable runnable =new thready(1);
Runnable run= new thready(2);
Thread t1=new Thread(runnable);
Thread t2=new Thread(run);
t1.start();
t2.start();
}}
Now from the output of this code, I think at any point in time only 1 thread is executing and the execution seems to alternate between the threads. Now i would like to know if my understanding of the situation is correct. And if it is I would like to know if there is any way in which i could get both threads to executing simultaneously as i wish to incorporate this scenario in a situation wherein i want to write a tcp/ip socket listener that simultaneously listens on 2 ports, at the same time. And such a scenario cant have any downtime.
Any suggestions/advice would be of great help.
Cheers
How many processors does your machine have? If you have multiple cores, then both threads should be running at the same time. However, console output may well be buffered and will require locking internally - that's likely to be the effect you're seeing.
The easiest way to test this is to make the threads do some real work, and time them. First run the two tasks sequentially, then run them in parallel on two different threads. If the two tasks don't interact with each other at all (including "hidden" interactions like the console) then you should see a roughly 2x performance improvement using two threads - if you have two cores or more.
As Thilo said though, this may well not be relevant for your real scenario anyway. Even a single-threaded system can still listen on two sockets, although it's easier to have one thread responsible for each socket. In most situations where you're listening on sockets, you'll spend a lot of the time waiting for more data anyway - in which case it doesn't matter whether you've got more than one core or not.
EDIT: As you're running on a machine with a single core (and assuming no hyperthreading) you will only get one thread executing at a time, pretty much by definition. The scheduler will make sure that both threads get CPU time, but they'll basically have to take turns.
If you have more than one CPU, both threads can run simultaneously. Even if you have only one CPU, as soon as one of the threads waits for I/O, the other can use the CPU. The JVM will most likely also try to dice out CPU time slices fairly. So for all practical purposes (unless all they do is use the CPU), your threads will run simultaneously (as in: within a given second, each of them had access to the CPU).
So even with a single CPU, you can have two threads listening on a TCP/IP socket each.
Make the threads sleep in between the println statements. What you have executes too fast for you to see the effect.
Threads are just a method of virtualizing the CPU so that it can be used by several applications/threads simultaneously. But as the CPU can only execute one program at a time, the Operating System switches between the different threads/processes very fast.
If you have a CPU with just one core (leaving aside hyperthreading) then your observation, that only one thread is executing at a time, is completely correct. And it's not possible in any other way, you're not doing anything wrong.
If the threads each take less than a single CPU quantum, they will appear to run sequentially. Printing 100 numbers in a row is probably not intensive enough to use up an entire quantum, so you're probably seeing sequential running of threads.
As well, like others have suggested, you probably have two CPU, or a hyperthreaded CPU at least. The last pure single core systems were produced around a decade ago, so it's unlikely that your threads aren't running side-by-side.
Try increasing the amount of processing that you do, and you might see the output intermingle. Be aware that when you do, System.out.println is NOT threadsafe, as far as I know. You'll get one thread interrupting the output of another mid-line.
They do run simultaneously, they just can't use the outputstream at the same time.
Replace your run- method with this:
public void run() {
for (int i=num;i<100;i++) {
try {
Thread.sleep(100);
System.out.println("Thread " + num + ": " + i);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
If you are getting many messages per second and processing each piece of data takes few milliseconds to few seconds, it is not a good idea to start one-thread per message. Ultimately number of threads spawned are limited by the underlying OS. You may get out-of-threads error or something like that.
Java 5 introduced Thread Pool framework where you can allocate a fixed number of threads and submit the job (instance of Runnable). This framework will run the job in one of the available thread in the pool. It is more efficient as there is not much context switching done. I wrote a blog entry to jump-start on this framework.
http://dudefrommangalore.blogspot.com/2010/01/concurrency-in-java.html
Cheers,
-- baliga
For the question on listening on 2 ports, clients has to send message to one of them. But since both ports are opened to accept connections within a single JVM, if the JVM fails having 2 ports does not provide you high-availability.
Usual pattern for writing a server which listen on a port is to have one thread listen on the port. As soon as the data arrives, spawn another thread, hand-over the content as well as the client socket to the newly spawned thread and continue accepting new messages.
Another pattern is to have multiple threads listen on the same socket. When client connects, connection is made to one of the thread.
Two ways this could go wrong:
System.out.println() may use a buffer, you should call flush() to get it to the screen.
There has to be some synchronisation
build into the System.out object or
you couldn't use it in a
multithreaded application without
messing up the output, so it is
likely that one thread holds a lock
for most of the time, making the other thread wait. Try using System.out in one thread and Sytem.err in the other.
Go and read up on multitasking and multiprogramming. http://en.wikipedia.org/wiki/Computer_multitasking