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.
Related
I've read somewhere that in Java scheduler, thread switching happens after execution of certain amount of instructions and not after a certain time (like schedulers used in operating systems). But the references were missing. I wanted to know if this is correct.
Java used to have a feature called GreenThreads, It was removed in 1.3. For all practical purposes we can assume that thread scheduling is directly influenced by the underlying operating systems's process/thread scheduling strategy. In this context, developers need to assume that threads are executed/scheduled randomly and should code/treat them as such.
On Linux the scheduling of Java threads is done using the Completely Fair Scheduler (CFS). For each CPU there is a run-queue and by default there is 24 ms in which all threads on a single-run queue should have a chance to run. So if there are 2 threads, each thread gets 12 ms, if there are 3 tasks, each thread gets 8 ms.
When tasks have a different priority, things chance. And also there is a minimum granularity to prevent reduce context switching overhead of many threads are running.
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.
In Java: Is it possible to prevent the scheduler (Ubuntu) to do a context-switch on a specific part of a thread-code.
And if so, how?
You should go for a realtime thread:
http://jrate.sourceforge.net/api/stable/javax/realtime/RealtimeThread.html
and set its priority to the maximum level:
http://docs.oracle.com/javase/1.5.0/docs/api/java/lang/Thread.html#setPriority%28int%29
This way, once the realtime thread is started, it won't release the processor anymore.
More, the scheduler should be asked to behave like a (realtime) FIFO scheduler.
You have a setScheduler() method.
What I do to avoid context switching is use thread affinity, busy waiting and isolating the cpus (if the OS supports that) Java doesn't support these so well but with the help of a little JNI/JNA it can be done.
Thread Affinity library for Java
Note: There are NMI interrupts which cannot be prevented but usually don't have much impact.
I'd like to use quartz in a project of mine. I know that there is a scheduler and a threadpool for the jobs.
Does the scheduler continuously run in its own thread and fires off the jobs?
If I run the app on a 2 core CPU will one core be busy with the scheduling thread?
Yes, quartz uses at least n+1 threads where 1 is the scheduler thread that is running in an infinite loop sleeping before next task that should be triggered. N is the number of worker threads in the threadpool. You can configure this number using the property org.quartz.threadPool.threadCount.
You can see it work by running the stuff through for example Eclipse and then in the debug view you can see the active and sleeping threads of the application.
Quartz will create a configurable pool of threads. Each job will fire in its own thread (of course, otherwise they can't run concurrently). And no, its not a busy loop so the scheduler won't claim a CPU for itself.
I am using swing and in my application i needed to run many threads in parallel like checking the internet connectivity after every 5 secs, monitoring the filesystem changes, sycing files from server.
All the time consuming tasks like above are running in SwingWorker so that my GUI should not freeze.
Same time i need to run some other time consuming tasks such as uploading file to server. for this purpose i also used swingWorker. and then i submit all these swingworker to executerService for thread pooling so that they should not effect each other.
My executer service is like this. i thought 30 threads will be enough for me.
static ExecutorService threadExecutor;
threadExecutor = Executors.newFixedThreadPool(30);
and then i submit threads in the same service.
threadExecutor.submit(monitorinternetconnectivity); //submitting swingworker obejct
Some of the threads i submit at the start and some i add runtime, when i add at runtime, it does not complete the job or stop running their job, like monitoring internet connectivity.
Is there any way to have the same functionality like swing worker, or some best way to use multiple swingworker. and we should be able to add new swingwokers at runtime to executer service
SwingWorker uses it's own ThreadPool.
SwingWorker should be used for a long running task after (i.e. anything that required more than a couple of milliseconds) after which a GUI update is required.
No calls to update gui elements outside the EDT should be done (i.e. from the SwingWorker.done() method)
If you generally follow the rules of accessing Swing components form inside the EDT (look here) then you shouldn't have a problem with locking. I suspect that the problem rather lies in your code but to be sure of that we should see it.