CODEWITHSUNDEEP
javamultithreadingscheduledexecutorservice
b36639
b36639

Reputation: 21

ScheduledExecutorService and Threads in Java

How does scheduler work here ? Does it create a new thread in the background and execute Run method in the main thread like a callback. ? . When run method is getting executedl, is it belong to the main thread?

 classA implements Runnable
 {
     
    public void Run()
    {
       System.out.println(Thread.currentTread().getName());
    }
    
    public static void main(String args[])
    {
      Thread.currentThread().setName("Main");
    
      ScheduledExecutorService scheduler = Executors.newSingleThreadScheduledExecutor();
      scheduler.scheduleAtFixedRate(this, 250, 250, TimeUnit.MILLISECONDS);
    
    } 
}

Thanks.

Upvotes: 2

Views: 4903

Answers (1)

GPI
GPI

Reputation: 9348

How does a SingleThreadScheduledExecutor work ?

It creates a thread pool that will at most contain one thread. This makes sure that only one task at a time (that is scheduled on this executor) will run.
Tasks run in the executor's single thread, not on the thread that has submitted them.

Can you make it so that the method runs on the "main thread" ?*

Well you can "make" anything, right ? But not with an ExecutorService, it is designed to work with its own thread.

How so then ?

Basically, either you're in an environment that provides everything to you (UI applications in Swing do for example), so check if this is your case (Swing has the Event Dispatch Thread). Either you nedd some work. So I'd first suggest you make sure you really NEED to work in the main thread before going on and doing this work.

What does this work involve ?

Without any special work, your main thread execute codes that is an ininteruptible flow of satements. They are written once, nobody can "inject" code into your main thread (well, unless you get really messy with your memory, which you can, but that is not something one usually do).

So your main thread is busy doing task A, then B, then C, then D in order, as fast as it can (or is allowed to). You can not inject "task E" in the middle of this flow.

Metaphorically, this would be the equivalent of chossing a random line in your code, and add statements of another method right there : crash guaranteed (what is the context, what is the stack, what variables exist at this particular line, and with which value : unpredictible). This can not happen.

And so, even if task A is "create a task to execute in 4 seconds", what will happen is : in another thread you get notified in 4 seconds that the timer expired, and this other thread will get to decide what to do, because the main thread is in the middle of doing "task B", and there is nothing else it can do.

So basically... it can't be done ?

Oh yes, it can. But you have to make "task A" (or B, or C), special for it to work. You have to design your main thread to periodically "wait" for events that come from outside.
And there is not a great many deal of ways to do that : periodically do something. You have to make your main thread performe an "loop". This pattern is called a run loop. Many many UI frameworks run this way.

What happens is that :

  1. you create a Queue, and make it globally accessible (Singleton pattern, for example) to your program. The goal of this queue will be to receive all the work units that the main thread is supposed to execute.
  2. Upon start, you make your main thread spawn a secondary thread that will be responsible to continue the initialization process and life of your application after step 3
  3. you make your main thread enter an infinite loop waiting for new events from the queue

With your "secondary" thread, you can then do anything you like, including setting your first timer. When the timer fires, it should send the work to be performed (say a Runnable instance ?) to the queue. The main thread will pick up that a run the runnable inline.

Is that efficient ? Waiting for events ?

Yes it can be. If you use well purposed objects (ConcurrentQueue ?) that are designed for concurrency, you do not actually perform work and waste resources while waiting. What happens under the hood is that threads are "signaled" by the operating system that new units are available. So it's not an infinite loop where you say "is there something to do ? If yes > do it, if no > wait three seconds". It's "Signal me when there's something to do".

I do not know of any JAR / lib or tool or best practice to actually implement this. Most of the times, either the environment provides this (Swing's ìnvokeLater), either I did not need this kind of things. So I know how this theoretically works, but I guess this is surprisingly difficult to actually implement right.

Wikipedia's entry for this pattern : http://en.wikipedia.org/wiki/Event_loop.
In game programming, one often have a "game loop" that is an equivalent pattern

Upvotes: 4

Related Questions