Can an Executor run multiple tasks on a single thread?
Obviously the task execution cannot happen simultaneously with only one physical core to run on, but is there a way to wait or yield so the other submitted tasks can run?
If there is not a wait then how else can one determine, generally, when the other task will run?
Yes.
Not with the current implementations.
No.
;)
Consider the documentation on SingleThreadExecutor (http://docs.oracle.com/javase/1.5.0/docs/api/java/util/concurrent/Executors.html#newSingleThreadExecutor()), and Wait between tasks with SingleThreadExecutor on StackOverflow.
You could implement your own thread-sharing lock between threads, and run them on a multi-thread executor... but if you want someone else's implementation to do that, well, as far as I know, you're out of luck.
Related
I have created an automated test suite which has a thread pool running simultaneously in the background of all test cases in order to obtain given system and performance metrics. Each thread is using a JSch connection to execute its shell commands and they are receiving [JSchException: Channel not opened exceptions].
The key problem is that the test suite continues to run forever, because the threads are not exiting even when all test cases have ended. But I'm not sure why...
When I checked the thread dump, I found that the threads do not exit because they are in a BLOCKED status.
Does anybody have an explanation for this? Or some help in resolving this issue?
I guess you mean the shutdownNow() method of ExecutorService. This is the documentation (I formatted the relevant parts in bold):
Attempts to stop all actively executing tasks, halts the processing of waiting tasks, and returns a list of the tasks that were awaiting execution.
This method does not wait for actively executing tasks to terminate. Use awaitTermination to do that.
There are no guarantees beyond best-effort attempts to stop processing actively executing tasks. For example, typical implementations will cancel via Thread.interrupt(), so any task that fails to respond to interrupts may never terminate.
Thread interruption is a cooperative process, your threads must be implemented so that they respond to interruption.
EDIT
1) About Thread.currentThread.interrupt() see this question: Why invoke Thread.currentThread.interrupt() when catch any InterruptException?
So you need to do this only if you have other methods/thread groups watching the interrupted status. In your case, probably not, but it does not hurt.
2) It seems that in "ShellUtils.executeCommand" you are running external programs. This could be the source of the problem if this method does not react to thread interruptions.
For example if i have a pool of 10 threads and these threads go out and start different processes (perl scripts), is there a way that those threads can "check up" on those scripts to see how they're doing?
Sometimes some of the scripts freeze up and I have no way of knowing. So i've been thinking of a way to have the threads check on the scripts every once in a while so I can be notified when a script is hung up so that i can start figuring out why they are hanging up and fix the problem.
For example if i have a pool of 10 threads and these threads go out and start different processes (perl scripts), is there a way that those threads can "check up" on those scripts to see how they're doing?
The only way that I know of to do this is if the script itself output some sort of status message every X seconds to standard-out or error and the thread that spawned the script was actively reading, waiting for the output. It then could update status information about the process.
If you use the ProcessBuilder and call start() to get a Process, then you can attach a BufferedReader to the process.getOutputStream() to monitor the script. You certainly can also call process.exitValue() to see if the process has finished but that won't tell you if it is hung.
Alternatively would be for the script to somehow call back to the monitoring process via a socket or some other IPC but I think just monitoring the output-stream is the best approach.
Actually, as I posted in a comment, knowing if a program is "hung-up" is an undecidable (can't be solved) problem called The halting problem. So it is not an option to verify on this.
Some alternate solutions would be to check if the script is still running by calling the isAlive() method on the Thread object that is running the script, or, as was told in other answers, to check for some output that the script might be giving, and interpret it. But by verifying output unfortunately you cannot be sure that the program is "hung-up", you can only know it's current state.
EDIT: If you want to wait a particular time, then you can use the Thread.sleep(long millis) call on the parent, and when it wakes up, check who's alive using, again isAlive(). But this doesn't guarantee either that the program will actually finish
is Eclipse 3.0 Jobs API using any internal thread pool for executing jobs?
or is it creating a new thread each time a job is scheduled (about to be started)?
if it doesn't use any thread pooling, is it somehow possible to use Jobs with Java's ExecutorService so that scheduled jobs will reuse existing threads from the Executor's pool?
if not then last question, is there a chance to provide progress feedback in the Eclipse progress view (as I'd do with Jobs IProgressMonitor) but from within a regular Java Thread?
I really like the features Jobs API provides (especially progress monitoring and cancellation) but I'm a bit concerned about the overhead it may introduce to the main UI thread if it doesn't use thread pooling and the jobs are scheduled really often.
thanks in advance!
regards,
jb.
Eclipse Jobs do use a fixed number of worker threads. Jobs are allocated to these worker threads, based on the priorities.
I cannot find any documentation stating that, but if you start your Eclipse instance in debug mode, you can see some worker threads in the thread list - these are the threads jobs are executed in.
I'm writing a single threaded program, which sometimes calls blocking methods (ie process.waitFor).
Can I be sure that the interrupted status of my thread is never set? Are there other conditions under which the JVM or the JRE standard library might decide to set the interrupt flag on my thread?
It seems true, but I couldn't find any mention about it in the Java docs.
If your application does not create any "Java" (java.lang.Thread) threads then I believe you can safely assume that your main thread will never be interrupted, see this dW article by Brian Goetz. Of course it is always possible that some library you're using could create threads and could potentially call interrupt() on your main thread, but it isn't likely.
In the end, I think you need to consider your requirements. The main purpose of the interrupt support in threads is so that tasks (threads) can be cancelled and so that applications can shutdown cleanly, even if some threads are suspended in blocking calls.
i have build a java clock with using timer,which works fine for a single task to alarm on next given/setted time, but i am having problem in scheduling multiple tasks(alarms for diff. times) with this timer, as two times can clash each other(same times for two different works) how to synchronize between such conditions, please help....
Thanks and Regards
Alok Sharma
I'm not sure what you're trying to do, but if you use quartz scheduler, you can resolve just about any scheduling/synchronisation task:
http://www.quartz-scheduler.org/
I agree with Lukas that you can use quartz. It is the best, scalable and robust solution.
But if you need something relatively small you can continue using timer based solution. As javadoc of Timer class indicates your tasks should take very few time. In this case you can forget about time clash. If your tasks take more then 0.1 seconds run them in separate thread. I mean use Timer as a trigger that just makes task to start in separate thread.
The thread may be done as following:
Create thread yourself. If you are in J2EE container it is bad practice. If you are in Tomcat it is ... not so bad.
Use thread pool. Comments about container are relevant here too.
Use JMS: Timer just pushes message to JMS. MDB or its equivalent receives message and performs task.
Using Timer itsef in J2EE container is a bad practice too. If you are there and wish to be "clean" use JCA to to run Timer.