I have a queue of tasks that need to be performed, and a pool of workers that pick up the tasks and perform them. There's also a "manager" class that keeps track of the worker, allows the user to stop or restart them, reports on their progress, etc. Each worker does something like this:
public void doWork() {
checkArguments();
performCalculation();
saveResultsToDatabase();
performAnotherCalculation();
saveResultsToDatabase();
performYetAnotherCalculation();
saveResultsToDatabase();
}
In this case, "database" does not necessarily refer to an Oracle database. That's certainly one of the options, but the results could also be saved on disk, in Amazon SimpleDB, etc.
So far, so good. However, sometimes the performCalculation() code locks up intermittently, due to a variety of factors, but mostly due to a poor implementation of networking code in a bunch of third-party libraries (f.ex. Socket.read() never returns). This is bad, obviously, because the task is now stuck forever, and the worker is now dead.
What I'd like to do is wrap that entire doWork() method in some sort of a timeout, and, if the timeout expires, give the task to someone else.
How can I do that, though ? Let's say the original worker is stuck in the "performCalculation()" method. I then give the task to some other worker, who completes it, and then the original worker decides to wake up and save its intermediate results to the database... thus corrupting perfectly valid data. Is there some general pattern I can use to avoid this ?
I can see a couple of solutions, but most of them will require some serious refactoring of all the business-logic code, from the ground up... which is probably the right thing to do philosophically, but is simply not something I have time for.
Have you tried using a Future? They are useful for running a task and waiting for it to complete, using a timeout etc. For example:
private Runnable performCalc = new Runnable() {
public void run() {
performCalculation();
}
}
public void doWork() {
try {
ExecutorService executor = Executors.newFixedThreadPool(1);
executor.submit(performCalc).get(); // Timeouts can be used here.
executor.submit(anotherCalc).get();
} catch(InterruptedException e) {
// Asked to stop. Rollback out transactions.
} catch(OtherExceptions here) {
}
}
If performCalculation stuck on blocking IO, there is little you can do to interrupt it. One solution is to close the underlying socket or set timeout on socket operations using Socket.setSoTimeout, but you have to own the code which reads from the socket to do that.
Otherwise you can add some reconciliation mechanism before saving the data into the database. Use some kind of timestamps to detect if the data in the database is newer that the data which original worker fetched from the network.
I suppose the easiest thing to do would be to have a separate timer thread, started when the thread with performCalculation() starts. The timer thread can wake up after a period of time and Thread.interrupt() the calculation thread, which can then perform any necessary rollback when handling the InterruptedException.
Granted, this is bolting on additional complexity to manage other problems, and consequently isn't the most elegant solution.
Related
One of the most suggested ways to pause a thread is to extend the Runnable interface by adding a pause() method:
interface RunnablePausable extends Runnable {
public void pause();
}
This never made sense to me since you don't actually want to pause the runnable but the Thread that runs it, in the same way you start/interrupt a Thread, not a Runnable.
A more elegant approach: since the interrupt() functionality is well built-in and supported by multiple methods, what if we interrupt() a Thread not just to terminate it, but for a general request instead (like you would interrupt a CPU, in a way)? And then let the Runnable handle this specific request
As an example: interrupt() the thread and, instead of straight up terminating it, handle its request to pause, stop, resume, or do anything else you like.
Not sure if this makes sense.
Something like this:
public void run() {
try {
//...
} catch (InterruptedException ie) { //interrupted
if (i_wanted_to_pause) { //manage request
//wait
}
if (i_wanted_to_stop) {
//return
}
if (any_other_request) {
//handle it
}
}
}
And:
public void run() {
if (Thread.currentThread().isInterrupted()) { //interrupted
if (request_to_pause) { //manage request
//wait
}
if (request_to_stop) {
//return
}
if (any_request) {
//handle it
}
}
}
Now the problem is: how to make a specific request to the interrupted thread?
How can I communicate my request to the interrupted thread, as if was meant to stop, pause, or do anything else?
Ideas:
Subclass InterruptedException into InterruptedExceptionStop and InterruptedExceptionPause (no idea how I can throw them)
Create a separate object containing the request. Don't know what would be the best way to achieve this without over-complicating things
Other?
Yes, as #markspace said in the comments, there is no any practical reason to request a thread to do things like pause/resume/etc at any moment(?).
The thread is just the calculation in general meaning. You know, there is the following popular pattern for CPU intensive executions:
ExecutorService es = Executors.newFixedThreadPool(Runtime.getRuntime().availableProcessors());
This means a thread ~= a CPU core. See a thread as a CPU core here. I believe this is an idiomatic view - a long-living sequential calculation, a conveyor. Do you think there should be a way to pause a CPU core by a user? To stop the conveyor by a button stuck to each box on it? I don't think so. So, if you want to prevent CPU from the calculation, just don't ask it to do the calculation. A classical example - Job/Task Queue baked with a thread and a BlockingQueue. You split your calculation into several jobs to consume them to the queue. If you don't consume new ones (optionally clear the queue), your thread is 'paused' naturally on take(). The same for IO, until you are OK to burn CPU with completely non-blocking solutions. With your code, you also have to take care about 3rd party things/objects you use in your run() to don't get them accidentally broken after the interruption, since it's true that "interruption == termination" is a commonplace semantically.
Another possible argument against the approach is mostly an architectural one. Runnable, Callable are examples of the IoC (Inversion of Control) pattern. But we introduce a control/execution management method into them, and this smells IMO.
If you had explained what was the specific problem you were trying to address, we would suggest a more suitable, more idiomatic than RunnablePausable approach.
Now, why do I like the question. It's inspiring to me when developers think about their things so deeply. It's nice when they invent something, even if these are their own homebrewed Continuations and Schedulers:) It may be an instructive game/experiment.
Suppose I have a nametag, which is UI component in GUI program.
The nametag will constantly change its text based on the data.
If the user change his/her name data, then he/she will see the change in nametag.
For this task, my code looks like this:
Thread thread = new Thread(new Runnable() {
#Override
public void run() {
while (true) {
String name = data.getName();
nametag.setText(name);
try {
Thread.sleep(100);
} catch (InterruptedException e) {
e.printStackTrace();
}
}
}
});
Since the reaction time of 0.1s seems instant to people, I included Thread.sleep(100) for computer to take a break.
However, I am not sure if that helps the computer in terms of energy usage or something. Is sleep method in this case complete waste of time? No benefit at all?
Thread.Sleep has been used for many things it shouldn’t be used for.
Here’s a list of the common mistakes:
The thread needs to wait for another thread to complete
In this case no value, other than infinite, passed to Thread.Sleep will be correct. You simply don’t know when the other thread will complete using this method. If the thread completed after Sleep returned you’ll likely have synchronization problems. If the other thread completed before Sleep returned the thread was needlessly blocked for an amount of time rendering the benefits of multithreading limited or moot. In the control circumstances where you’ve tested this it may seem like it always works; it just takes a busy program to cause it to faile: a defrag program, a sudden influx of network traffic, a network hiccup, etc.
The thread needs perform logic every n milliseconds
As noted earlier, Sleep means relinquish control. When your thread gets control again isn’t up to the thread; so it can’t be used for periodic logic.
We don’t know why Thread.Sleep is required; but if we take it out the application stops working
This is flawed logic because the application still doesn’t work with Thread.Sleep. This is really just spackling over the problem on that particular computer. The original problem is likely a timing/synchronization issue, ignoring it by hiding it with Thread.Sleep is only going to delay the problem and make it occur in random, hard to reproduce ways.
Source: http://blogs.msmvps.com/peterritchie/2007/04/26/thread-sleep-is-a-sign-of-a-poorly-designed-program/
This doesn't answer your direct question, but it does help address an XY Problem component of your question:
It looks like you're listening for object state changes by polling: by constantly testing an object to see what its state is and whether it's changed, and this is a bad idea, especially when coding for an event-driven GUI. Much better to use an observer pattern and be notified of state changes when or if they occur. That is how the Swing GUI library itself was written, and you should strongly consider emulating this.
Some ways to be notified of changes are to use component event listeners which can listen for changes to Swing components, such as ActionListeners, ChangeListeners, ItemListeners, and the like. Another way when listening to non Swing component items is to use SwingPropertyChangeSupport and PropertyChangeListeners and in this way to create "bound" properties of your class. This is often used for non-GUI model classes.
I have a javaFX application which visualizes compuational geometry algorithms. The execution of an algorithm happens in another thread, lets call it mainComputingThread.
An algorithm can update the UI at any time by adding/removing/modifying shapes.
so the code will look like:
//do some computaions (1)
updateUI();
//do some more calculations (2)
What I want know is in the updateUI method to update the UI immediately and prevent the calling thread from running further (marked as (2)) until the UI update is done.
I thought about boolean guards. So the code could would look like:
updateUI(){
boolean guard = false;
Platform.runLater(new Runnable()
{
run(){
//do the actual update
guard = true;
}
});
while(guard==false);
}
I hope you get an idea of what I mean. I'm really curious if there's a better solution for this problem...
Simple approach: block background thread until update is complete:
You need to update the UI on the FX Application Thread. Typically you do this by passing a plain Runnable to Platform.runLater(...).
If you want to wait for that ui update to complete before proceeding, instead create a FutureTask and pass it to Platform.runLater(...). Then you can call get() on the FutureTask, which will block until the task is complete:
private void updateUI() throws InterruptedException {
// actual work to update UI:
FutureTask<Void> updateUITask = new FutureTask(() -> {
// code to update UI...
}, /* return value from task: */ null);
// submit for execution on FX Application Thread:
Platform.runLater(updateUITask);
// block until work complete:
updateUITask.get();
}
This lets the FutureTask handle all the tricky work of waiting and notifying: it is always better to use a higher-level API for this kind of work when you can.
If you like, you can refactor this into a utility method, similarly to Dainesch's answer:
public class FXUtils {
public static void runAndWait(Runnable run) throws InterruptedException {
FutureTask<Void> task = new FutureTask<>(run, null);
Platform.runLater(task);
task.get();
}
}
Alternative approach: ensure that no more than one update is consumed during any frame rendering, blocking the background thread if an update is pending
Here is a somewhat different approach. Create a BlockingQueue with a capacity of 1 to hold the Runnables that update the UI. From your background thread, submit the Runnables to the blocking queue: since the blocking queue can hold at most one element, this will block if one is already pending.
To actually execute the updates in the queue (and remove them, so more can be added), use an AnimationTimer. This looks like:
private final BlockingQueue<Runnable> updateQueue = new ArrayBlockingQueue<>(1);
background thread code:
// do some computations...
// this will block while there are other updates pending:
updateQueue.put(() -> {
// code to update UI
// note this does not need to be explicitly executed on the FX application
// thread (no Platform.runLater()). The animation timer will take care of that
});
// do some more computations
Create the timer to consume the updates:
AnimationTimer updateTimer = new AnimationTimer() {
#Override
public void handle(long timestamp) {
Runnable update = updateQueue.poll();
if (update != null) {
// note we are already on the FX Application Thread:
update.run();
}
}
};
updateTimer.start();
This basically ensures that no more than one update is ever scheduled at any time, with the background thread blocking until any pending updates are consumed. The animation timer checks (without blocking) for pending updates on each frame rendering, ensuring that every update is executed. The nice thing about this approach is that you can increase the size of the blocking queue, effectively keeping a buffer of pending updates, while still ensuring no more than one update is consumed during any single frame rendering. This might be useful if there are occasional computations that take longer than others; it gives these computations a chance to be calculated while others are waiting to be executed.
Hard question to answer without having the reason why you want to stop processing before the UI update is done. (Note: the runLater method executes the UI updates in the order received) Is it to prevent spamming to many Runnables to the JavaFX thread? Other reasons?
Your basic idea however works with the use of a CountDownLatch so that the processing thread waits to acquire a permit. If you choose that approach use something like this:
public class MyFXUtils {
public static runAndWait(final Runnable run) {
final CountDownLatch doneLatch = new CountDownLatch(1);
Platform.runLater(new Runnable() {
public void run() {
try {
run.run();
} finally {
doneLatch.countDown();
}
}
});
doneLatch.await();
}
}
EDIT: replaced Semaphore by CountDownLatch
EDIT:
So, the quickest way I always do it in prototypes is as following, transform:
//do some computaions (1)
updateUI();
//do some more calculations (2)
into
ExecutorService executor = Executors.newFixedThreadPool(1);
class JobStep implements Runnable {
public void run() {
doSomeComputations();
Platform.runLater(() -> {
updateUI();
executor.submit(new JobStep());
});
}
executor.submit(new JobStep());
OLD PART
Not an answer, but a suggestion how to attack the problem.
From my experience, the complete solution would be much more elaborate. I would separate the JavaFX shape instances from the shapes, which your algorithm does process. I would do it by means of using different class types and synchronize between the two.
The graphical algorithms have the tendency to be a lot quicker than the ones that are visualizing it. If the algorithm runs on small data set, then the rendering most often tend to slow down it significantly. It can easily be seen by running the same algorithm with and without visualization.
If the data set is bigger than the most trivial ones, then drawing of a single frame can easily take more than one second. Interactive visualizations are expected to respond in "real time", preferably many times per second.
The data visualization facilities have many means to tackle the problem. The best candidates always include:
Simplifying visualization. Drawing simpler shapes instead of complex, like removing the rounding from boxes. The LOD (level of detail) also applies to this point: during interactive scroll the visualized elements might be replaced by bounding box counterparts.
Selective hiding. Drawing only a part of the whole data set.
Parallelizing and hardware acceleration. The GPU's natively provide many means to handle complex visualizations. Typically the low level programming APIs (OpenGL, shader programs) allow much better throughput than every high level wrapping API, including JavaFX
Most often, the end solutions incorporate not only above points, but also others, including domain specific optimizations.
The visualization facilities always come with a lot of restrictions, like the most common one: have to be updated in the dedicated thread (thread confinement approach). They also come with visualization specific data structures.
From the data processing algorithm stage, one of the most common requirements is that it cannot be blocked or delayed by visualization. The algorithms are also written in a style, which doesn't translate to well for the means of visualization: imperative loops over data structures instead of updating observable drawable objects. There is a good reason to it though: the algorithms are expected to be optimized for performance or memory consumption.
One architectural approach to the problem might be as following:
The data processing stage produces snapshots at predefined points. The adding, modifying and remove operations are all published as this packet. It can be a just a copy of data structure that is being processed or it can be in the form of the coalesced events.
The data processing and data visualization run on different threads. They communicate only by means of publishing snapshots, never by blocking each other directly.
The snapshots shouldn't be restricted to particular frame rate. There should be means to batch updates before drawing or drawing same batch multiple times if the data processing stage stalls.
I strongly recommend reactive approach to the problem. The RxJava provides nice example for the "suggestion box" feature. It's very good at correctly handling requirements like "Every key update do a long running process on different thread and discard the last one, if any was running. Or maybe, don't do it on every key update, but wait 50ms for the user to make up his mind before he ends typing".
I'm working on a Java-based server in which I will have multiple threads (one thread for each connected user + some extra). There will be some database connection involved, so I was thinking that each time the server makes a SELECT query to the database it will start a new thread for this, to prevent blocking from the current thread. I'm planning on using a connection pool for this and I think I know how to do that. (I've looked into C3P0) However, there will be a lot of UPDATE statements involved also, but it's not important that these are ran directly, it's ok with a delay here. And since there might be a lot of UPDATE statements, I'm thinking of having a single worker thread for all UPDATE statements. As I see it, this will have the advantage of being able to re-use PreparedStatement-objects
The question:
How can I, from the other threads, tell the UPDATE-worker thread to run some statements? I know about multithreading and how to make threads "talk" to each other using synchronized blocks, but with the database involved it suddenly feels more complex. I have read that prepared statements and connections should not be shared between threads.
The idea I have right now on how to solve it: (doesn't feel like a good solution)
Use a LinkedBlockingQueue (or another kind of Queue) of a custom class with information about which kind of UPDATE statement to call and which parameters to send it. And then the worker thread will read from this queue when it's notified (which it will be when something is added to the queue) and there it will run the appropriate method which will use the appropriate prepared statement, set the params, and call it.
Edit: A bad think that I see myself with this approach is that the params might be ints, String, double, or whatever. How to store them in the custom class? Doesn't feel good to store them all as String.
Am I on the right track here or is there a better way to solve this?
No need for an explicit blocking queue. You can have a worker thread and a work queue encapsulated by an ExecutorService. As for the values, you can use generics:
class ThreadTask<T> implements Runnable {
private T value;
public ThreadTask(T value) {
this.value = value;
}
public void run() {
// update based on value
}
}
...
ExecutorService exec = Executors.newSingleThreadExecutor();
exec.submit(new ThreadTask<String>("asdf"));
exec.submit(new ThreadTask<Integer>(1));
The single thread executor is simply a worker thread waiting on a queue and executing the submitted tasks in order. No need for other explicit management.
I have an application which spawns a new thread when a user asks for an image to be filtered.
This is the only type of task that I have and all are of equal importance.
If I ask for too many concurrent threads (Max I ever want is 9) the thread manager throws a RejectedExecutionException.
At the minute what I do is;
// Manage Concurrent Tasks
private Queue<AsyncTask<Bitmap,Integer,Integer>> tasks = new LinkedList<AsyncTask<Bitmap,Integer,Integer>>();
#Override
public int remainingSize() {
return tasks.size();
}
#Override
public void addTask(AsyncTask<Bitmap, Integer, Integer> task) {
try{
task.execute(currentThumbnail);
while(!tasks.isEmpty()){
task = tasks.remove();
task.execute(currentThumbnail);
}
} catch (RejectedExecutionException r){
Log.i(TAG,"Caught RejectedExecutionException Exception - Adding task to Queue");
tasks.add(task);
}
}
Simply add the rejected task to a queue and the next time a thread is started the queue is checked to see if there is a backlog.
The obvious issue with this is that if the final task gets rejected on its first attempt it will never be restarted (Until after it's no longer needed).
Just wondering if there's a simple model I should use for managing this sort of thing. I need tasks to notify the queue when they are done.
The reason for the RejectedExecutionException is because AsyncTask implements a thread pool of its own (per Mr. Martelli's answer), but one that is capped at a maximum of 10 simultaneous tasks. Why they have that limit, I have no idea.
Hence, one possibility is for you to clone AsyncTask, raise the limit (or go unbounded, which is also possible with LinkedBlockingQueue), and use your clone. Then, perhaps, submit the change as a patch to AsyncTask for future Android releases.
Click here to run a Google Code Search for AsyncTask -- the first hit should be the implementation.
If you just want to raise the limit, adjust MAXIMUM_POOL_SIZE to be as big as you're likely to need. If you want to go unbounded, use the zero-argument LinkedBlockingQueue constructor instead of the one being presently used. AFAICT, the rest of the code probably stays the same.
You seem to have implemented a version of the Thread Pool design pattern -- the wikipedia article points to many helpful articles on the subject, which may help you refine your implementation. I also recommend this Java-specific article which has clear code and explanation.
Maybe an option is to have the task wait on a blocking queue (of bitmaps) instead of taking bitmap as a parameter, but you will have to add a way for the task(s) to terminate.